EMC: 03jthornton 07master * rc872d0c569e6 10/docs/src/gui/gladevcp.lyx: fix markup errors
EMC: 03jthornton 07master * r7724aed24e4f 10/docs/src/gui/gladevcp.lyx: add gladevcp programming
dgarr: about the problem you reported - I didn't ever come up with the right change, so I've done nothing. Both of our changes made the behavior worse.
dgarr: I got bogged down trying to figure out how it should work - you can have current tool offsets that came from anywhere, including this tool's old tool table entry (G43), another tool (G43 H[other]), or a dynamic tool offset (G43.1 X...Y...Z...)
dgarr: I have trouble even seeing what G10 L10 should do in all those cases
JT-Shop: how should I come back with changes? 'd rather edit source and post results in my repo so you can fetch it?
yea, just buzz me at jthornton with a link
cradek: thanks for looking at it -- too complicated for me
me too, apparently
can you reject it when there's a rotation and exactly one of x or y is specified?
.. or is my impression that the "is rotated" case is the problem?
I think what G10 L10 should do is make it so if that tool offset were subsequently loaded with other offsets set as they are now, the axes specified on the G10 L10 would become the specified values, and the other axes would still be the same as if the TLO was loaded before having done the G10 L10
.. or is my impression that the "is rotated" case is the problem wrong?
currently, it breaks if you set only one of X and Y values, then without doing the G43 to load the new offset, set the other one with another G10
with dewey's patch, everything breaks if you are rotated
with my patch, everything breaks differently (haha)
jepler: are you satisfied with drawing time of 20ms per graph line?
psha: that's 50hz, should look pretty smooth
it's for one graph line
for 4 it's 12 fps i think
psha: for scope2 I can't restrict coordinates to having integral X or Y values
or having exactly 1 sample per integral number of X values
it's not scope2 limitations
just small adjustments to scale
i think even any rational number may be allowed
with more work
point is in fast partitioning of array
to determine which samples should be drawn?
* cradek waits for someone to say "yeah, I agree that's what G10 L10 should do, and I bet I can fix it"
cradek: not for you :-P
wait wait wait wait wait
* jepler waits 5 times
jepler: i've measured times for partitioning and drawing - they compared as 4:1 before using fast numpy reshape
with numpy it's 15ms for drawing and 5ms for preparing array
unfortunately with AXIS you can't set X and Y together, so tool touch off is fairly broken for X,Y unless you mdi G43 between them
I thought tool touch off would issue the G43 for you
oh - you are right - I think AXIS does that
jepler: on my main comp i've 5ms per drawing graph line and 10ms for partitioning
ah, sorry, 1ms
so it's 6ms per graph
how many points of graph are visible? With halscope perhaps you have a 1ms servo thread and set the horizontal scale for 1 sec/div, so that's 10000 samples visible even if the screen is only 1024 across..
1024 samples for 1024 width
i'm partitioning array into 'width' subarrays and calculate mean values
that's the part of the work that takes 1ms?
it's better to show alsy min/max along with mean
like it's done in rrd
yes, you sure want to be sure the extremes are visible!
like a 1ms glitch in position feedback or velocity command
min/max values adds some extra weight to drawing but not extremly high
only when you have min/max values covering whole rectangle :)
ah, stupid me
instead of writing lot of lines it's better to fill area i think
hm, lines are faster :)
over here gdk_draw_lines can draw 10000 lines in a 1000x1000 drawing area in about 1ms including a gdk_display_sync to make sure the server's finished the painting request
(a standalone C program)
actually, 10239 lines connecting 10240 points, but who's counting
yes, in C
the similar cairo program gets about 5ms per draw
I'll do a third for gtkgl and then put all of them online
maybe, i've seen benchmarks only for more complex drawings like filling rectangles
gtkgl may rule them all :)
it's about the same speed as gdk_draw_lines, consistently just a little bit below 1ms
.. but that's with 10k glVertex2d calls, not a single glDrawElements call which would probably be faster
heh, 1ms is low enought to be happy )
mhaberler_: i'm now with read-only email :) so i've read you letters but not able to anwser :)
and i'm in the subway off to the city ... late ttonight i'll retry
mhaberler_: idea of MDI command widget is nice
hi nanorobot general
i am not a general ^^
psha: what is your passion?
kidding and trolling! :)
those nanomills looks good for small shops.. :)
модернизация и нанотехнологии етм!
Sansiba: last years our 'government' spending huge amounts of money on 'nanotechnology'
Sansiba: so if you want to get government contract you have to add word 'nano' somewhere
spend like throw in the river
psha: oh ok, where are you from
A large country and such a small technology^^
psha: What is the goal of what Russia is doing this Nano?
our nano technology will be biggest in the world!! as microchips were..
Sansiba: i don't know what's english equivalent of word 'raspilit'...
but with this 'nanotechnology' most of science funds went into it
and dissappeared somewhere
psha: you mean Spray?
no, it's russian word for 'to saw' :)
a milling machine
means that funding is sawed into parts and dissapears
it's a word describing financial policitcs of our country :)
mhaberler_: btw i've found that my estop actions were not correct - there is more preciese 'ToggleAction' base class for them
I can not follow you, unfortunately, what's the advantage?
i'm currently working on improvements in GladeVcp
it's for some yet unreleased part of it
psha: my real mill is not exposed to you code :-)
mhaberler_: that's right descision :)
drawing a trace of 10240 samples on a 1024x1024 window: cairo: 257fps max. gdk: 1490fps max. opengl: 2700fps max
of course, no two of the drawings look exactly the same
to my surprise, using VBOs with GL_STATIC_DRAW_ARB once doesn't speed things up compared to just doing good old fashioned GL_VERTEX_ARRAY
video is GeForce 8400GS
[20:14:50] <jepler> http://emergent.unpy.net/files/sandbox/drawtrace.tar.gz
make, then run one of the 4 programs, and make it expose itself by e.g., waggling another window on top of it
hum! changing to redraw from a g_timeout_add that calls gtk_widget_queue_draw has heavily changed the timings
.. I trust it a bit more actually
jepler: it's not .gz but plain tar :)
updated (and a tar.gz this time, I think)
with same contents?
no, with a change to have a g_timeout_add that calls gtk_widget_queue_draw so you don't have to waggle
new results: cairo goes down to 57fps, gdk goes down to 777fps, gl goes up to 27445fps, glvbo goes up to 49833fps
draw time: 6,78ms [ 147,5fps], best: 3,10ms 322,2fps
draw time: 12,14ms [ 82,4fps], best: 3,10ms 322,2fps
draw time: 43,72ms [ 22,9fps], best: 19,31ms 51,8fps
draw time: 32,88ms [ 30,4fps], best: 19,31ms 51,8fps
draw time: 16,38ms [ 61,0fps], best: 4,75ms 210,7fps
draw time: 21,47ms [ 46,6fps], best: 4,07ms 245,8fps
mine's nvidia with proprietary driver
ati HD2400 with oss driver
since many people running emc will not have accelerated opengl I think I will continue with gdk as the drawing api, not cairo or opengl.
mhaberler__ is now known as mhaberler_
.. and even some people with accelerated opengl will see gdk be faster than opengl, which is interesting to me
oss ati driver has 2d faster then 3d :)
and it's 2d is on par with closed driver
how experienced do you consider yourself as a user of the cairo APIs?
written two widgets using it :)
in scope2 there was something that was preventing me from using the CTM to scale my graphs: I had nonuniform scales (e.g., in X I had 1 = 1 sample and in Y I had 1 = 1 unit of the sampled value. But when you have a non-uniform scaling, I couldn't determine how to get a circular pen
gladevcp is third time i'm involved in GUI :)
the only related API I see, cairo_set_line_width takes just one number and notes that "The line width value specifies the diameter of a pen that is circular in user space, (though device-space pen may be an ellipse in general due to scaling/shear/rotation of the CTM)."
ctm == current transform matrix?
of course it's just like postscript in this respect
yes, it's transformed too...
psha: oh duh
place cv.save before scale and cv.restore before stroke
and it's working :)
i've got very thick lines with fixed width
cairo may be is slowest for drawing 10k lines but i think features it provides (like simple transformations) overweight this performance issue
also i still don't see point in drawing all 10k samples on 1k resoultion
may be better to wrap stroke instead of path creation: http://lists.freedesktop.org/archives/cairo/2008-June/014292.html
it's from same thread
thanks, that's very informative!
weird, I wonder why cairo dropped support for the glitz back-end without a replacement
i thought there was some work in opengl direction
I guess the development versions have something called cairo-gl now. http://cairographics.org/news/cairo-1.9.6/
[21:48:21] <psha> http://thread.gmane.org/gmane.comp.lib.cairo/17377
at this point it's not routinely beating xlib or image by a factor of even 5, though
it's dependent on gpu i think
his tests are on intel gpu which is pretty slow
i think on nvidia/ati card difference will be higher
I'll run my tests again this evening on a laptop with intel integrated video
incidentally, building the path is not the intensive thing in my test program. buildince it once on the first place and reusing it via the cairo_append_path API doesn't speed anything.
for unknown reasons opengl backend is disabled in cairo debian packages
ubuntu 10.04's cairo is to old to have the new gl backend
my squeeze machine isn't available at the moment for me to check there
there also doesn't seem to be documentation on how to use that backend in http://cairographics.org/manual/
debian has 1.8 but 1.10 in experimental
I will have to figure out experimental. the latest icewweasel 4.0beta (which comes from its own apt repository) won't install, and it looks like the reason is that it depends on packages in experimental
experimental is ususally better then unstable :)
at least when you try to install something it cries 'hey man, do you really want to install THAT?!"
and with unstable it silently installs you tons of broken crap :)
jepler: at least for me cairo-gl is not fast...
mhaberler__ is now known as mhaberler
jepler, my drawtrace http://paste.debian.net/103046/
qq-: interesting, thanks
what opengl? software?
squeeze, on acer aspire laptop
my laptop with intel video gets 204fps gdk, 256fps glvbo, 270fps gl, 58fps cairo
hm there's a terrible memory leak in the cairo demo
well that's interesting
with the missing cairo_destroy call to fix the memory leak, it's also improved the speed
ah, no, on second thought that's not it
I also made the trace vary; sometimes the trace is very short, and cairo must optimize the case where the drawn area is a smaller rectangle