Back
[14:17:38] <CIA-60> EMC: 03jthornton 07master * rc872d0c569e6 10/docs/src/gui/gladevcp.lyx: fix markup errors
[14:17:42] <CIA-60> EMC: 03jthornton 07master * r7724aed24e4f 10/docs/src/gui/gladevcp.lyx: add gladevcp programming
[15:22:46] <cradek> 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.
[15:33:44] <JT-Shop> mhaberler:
http://www.linuxcnc.org/docview/devel/html/gui_gladevcp.html
[15:46:03] <cradek> 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...)
[15:46:26] <cradek> dgarr: I have trouble even seeing what G10 L10 should do in all those cases
[16:20:31] <mhaberler> JT-Shop: how should I come back with changes? 'd rather edit source and post results in my repo so you can fetch it?
[16:26:14] <JT-Shop> yea, just buzz me at jthornton with a link
[16:33:52] <dgarr> cradek: thanks for looking at it -- too complicated for me
[16:35:57] <cradek> me too, apparently
[16:37:15] <jepler> can you reject it when there's a rotation and exactly one of x or y is specified?
[16:37:23] <jepler> .. or is my impression that the "is rotated" case is the problem?
[16:37:54] <cradek> 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
[16:37:55] <jepler> .. or is my impression that the "is rotated" case is the problem wrong?
[16:38:43] <cradek> 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
[16:38:53] <cradek> with dewey's patch, everything breaks if you are rotated
[16:38:59] <jepler> I see.
[16:39:22] <cradek> with my patch, everything breaks differently (haha)
[16:40:04] <psha> jepler: are you satisfied with drawing time of 20ms per graph line?
[16:40:43] <jepler> psha: that's 50hz, should look pretty smooth
[16:41:35] <psha> it's for one graph line
[16:41:42] <psha> for 4 it's 12 fps i think
[16:41:51] <jepler> psha: for scope2 I can't restrict coordinates to having integral X or Y values
[16:42:20] <jepler> or having exactly 1 sample per integral number of X values
[16:42:34] <psha> it's not scope2 limitations
[16:42:41] <psha> just small adjustments to scale
[16:43:37] <psha> i think even any rational number may be allowed
[16:43:56] <psha> with more work
[16:44:51] <psha> point is in fast partitioning of array
[16:45:16] <jepler> to determine which samples should be drawn?
[16:45:52] <cradek> * cradek waits for someone to say "yeah, I agree that's what G10 L10 should do, and I bet I can fix it"
[16:45:53] <psha> yes
[16:46:08] <psha> cradek: not for you :-P
[16:46:24] <cradek> wait wait wait wait wait
[16:46:35] <jepler> * jepler waits 5 times
[16:47:03] <psha> jepler: i've measured times for partitioning and drawing - they compared as 4:1 before using fast numpy reshape
[16:47:27] <psha> with numpy it's 15ms for drawing and 5ms for preparing array
[16:47:36] <cradek> 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
[16:47:54] <jepler> I thought tool touch off would issue the G43 for you
[16:48:14] <cradek> oh - you are right - I think AXIS does that
[16:59:46] <psha> jepler: on my main comp i've 5ms per drawing graph line and 10ms for partitioning
[16:59:53] <psha> ah, sorry, 1ms
[16:59:57] <psha> so it's 6ms per graph
[17:00:18] <psha> ~170 fps
[17:08:51] <jepler> 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..
[17:10:54] <psha> 1024 samples for 1024 width
[17:11:24] <psha> i'm partitioning array into 'width' subarrays and calculate mean values
[17:11:49] <jepler> that's the part of the work that takes 1ms?
[17:12:12] <psha> yes
[17:12:26] <psha> it's better to show alsy min/max along with mean
[17:12:29] <psha> like it's done in rrd
[17:12:47] <jepler> yes, you sure want to be sure the extremes are visible!
[17:12:58] <jepler> like a 1ms glitch in position feedback or velocity command
[17:18:21] <psha> min/max values adds some extra weight to drawing but not extremly high
[17:18:57] <psha> only when you have min/max values covering whole rectangle :)
[17:26:15] <psha> ah, stupid me
[17:26:51] <psha> instead of writing lot of lines it's better to fill area i think
[17:28:27] <psha> hm, lines are faster :)
[17:49:15] <jepler> 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
[17:50:26] <jepler> (a standalone C program)
[17:51:21] <jepler> actually, 10239 lines connecting 10240 points, but who's counting
[17:55:48] <psha> in C?
[17:56:04] <jepler> yes, in C
[17:57:08] <jepler> the similar cairo program gets about 5ms per draw
[17:57:27] <jepler> I'll do a third for gtkgl and then put all of them online
[17:57:38] <psha> maybe, i've seen benchmarks only for more complex drawings like filling rectangles
[17:57:52] <psha> gtkgl may rule them all :)
[18:09:56] <jepler> it's about the same speed as gdk_draw_lines, consistently just a little bit below 1ms
[18:12:09] <jepler> .. but that's with 10k glVertex2d calls, not a single glDrawElements call which would probably be faster
[18:13:40] <psha> heh, 1ms is low enought to be happy )
[18:44:18] <psha> mhaberler_: i'm now with read-only email :) so i've read you letters but not able to anwser :)
[18:45:40] <mhaberler_> and i'm in the subway off to the city ... late ttonight i'll retry
[19:43:50] <psha> mhaberler_: idea of MDI command widget is nice
[19:44:01] <Sansiba> hi @ll
[19:44:13] <psha> hi nanorobot general
[19:44:38] <Sansiba> hi psha
[19:45:03] <Sansiba> i am not a general ^^
[19:45:15] <dimas_> :)
[19:45:35] <Sansiba> psha: what is your passion?
[19:46:00] <psha> kidding and trolling! :)
[19:46:03] <dimas_> those nanomills looks good for small shops.. :)
[19:46:14] <psha> dimas_: nanoshops!
[19:46:27] <psha> модернизация и нанотехнологии етм!
[19:46:41] <Sansiba> oh
[19:46:41] <dimas_> yeah, nanoeverythings
[19:47:12] <psha> Sansiba: last years our 'government' spending huge amounts of money on 'nanotechnology'
[19:47:59] <psha> Sansiba: so if you want to get government contract you have to add word 'nano' somewhere
[19:48:46] <dimas_> spend like throw in the river
[19:49:02] <Sansiba> psha: oh ok, where are you from
[19:49:17] <psha> russia :)
[19:50:27] <Sansiba> A large country and such a small technology^^
[19:51:43] <Sansiba> psha: What is the goal of what Russia is doing this Nano?
[19:52:12] <dimas_> our nano technology will be biggest in the world!! as microchips were..
[19:52:29] <psha> Sansiba: i don't know what's english equivalent of word 'raspilit'...
[19:52:59] <psha> but with this 'nanotechnology' most of science funds went into it
[19:53:05] <psha> and dissappeared somewhere
[19:53:41] <Sansiba> psha: you mean Spray?
[19:54:30] <psha> no, it's russian word for 'to saw' :)
[19:54:41] <Sansiba> oh ok
[19:54:46] <Sansiba> a milling machine
[19:54:55] <psha> means that funding is sawed into parts and dissapears
[19:55:15] <psha> it's a word describing financial policitcs of our country :)
[19:55:55] <Sansiba> oh
[19:56:05] <psha> mhaberler_: btw i've found that my estop actions were not correct - there is more preciese 'ToggleAction' base class for them
[19:57:00] <Sansiba> I can not follow you, unfortunately, what's the advantage?
[19:58:18] <psha> i'm currently working on improvements in GladeVcp
[19:58:26] <psha> it's for some yet unreleased part of it
[19:58:55] <mhaberler_> psha: my real mill is not exposed to you code :-)
[19:59:37] <psha> mhaberler_: that's right descision :)
[20:09:29] <jepler> drawing a trace of 10240 samples on a 1024x1024 window: cairo: 257fps max. gdk: 1490fps max. opengl: 2700fps max
[20:09:50] <jepler> of course, no two of the drawings look exactly the same
[20:11:38] <jepler> 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
[20:12:47] <jepler> video is GeForce 8400GS
[20:14:50] <jepler> http://emergent.unpy.net/files/sandbox/drawtrace.tar.gz
[20:15:17] <jepler> make, then run one of the 4 programs, and make it expose itself by e.g., waggling another window on top of it
[20:18:46] <jepler> hum! changing to redraw from a g_timeout_add that calls gtk_widget_queue_draw has heavily changed the timings
[20:19:00] <jepler> .. I trust it a bit more actually
[20:19:41] <psha> jepler: it's not .gz but plain tar :)
[20:19:45] <jepler> psha: oops!
[20:20:59] <jepler> updated (and a tar.gz this time, I think)
[20:21:15] <psha> with same contents?
[20:21:48] <jepler> no, with a change to have a g_timeout_add that calls gtk_widget_queue_draw so you don't have to waggle
[20:22:28] <jepler> new results: cairo goes down to 57fps, gdk goes down to 777fps, gl goes up to 27445fps, glvbo goes up to 49833fps
[20:23:34] <psha> draw time: 6,78ms [ 147,5fps], best: 3,10ms 322,2fps
[20:23:35] <psha> draw time: 12,14ms [ 82,4fps], best: 3,10ms 322,2fps
[20:23:36] <psha> gdk
[20:23:47] <psha> draw time: 43,72ms [ 22,9fps], best: 19,31ms 51,8fps
[20:23:49] <psha> draw time: 32,88ms [ 30,4fps], best: 19,31ms 51,8fps
[20:23:50] <psha> cairo
[20:24:02] <psha> draw time: 16,38ms [ 61,0fps], best: 4,75ms 210,7fps
[20:24:05] <psha> gldraw
[20:24:15] <psha> draw time: 21,47ms [ 46,6fps], best: 4,07ms 245,8fps
[20:24:17] <psha> glvbo
[20:24:24] <jepler> what video?
[20:24:38] <jepler> mine's nvidia with proprietary driver
[20:24:41] <psha> ati HD2400 with oss driver
[20:26:03] <jepler> 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.
[20:26:03] <mhaberler__> mhaberler__ is now known as mhaberler_
[20:26:22] <jepler> .. and even some people with accelerated opengl will see gdk be faster than opengl, which is interesting to me
[20:29:39] <psha> oss ati driver has 2d faster then 3d :)
[20:30:02] <psha> and it's 2d is on par with closed driver
[20:32:26] <jepler> how experienced do you consider yourself as a user of the cairo APIs?
[20:34:10] <psha> written two widgets using it :)
[20:34:21] <jepler> 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
[20:34:38] <psha> gladevcp is third time i'm involved in GUI :)
[20:34:43] <jepler> 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)."
[20:36:35] <psha> ctm == current transform matrix?
[20:37:12] <jepler> yes
[20:40:26] <jepler> of course it's just like postscript in this respect
[20:48:48] <psha> yes, it's transformed too...
[20:49:00] <psha> after cr.scale()
[20:51:32] <psha> jepler:
http://lists.freedesktop.org/archives/cairo/2008-June/014286.html
[20:52:14] <jepler> psha: oh duh
[20:52:30] <psha> place cv.save before scale and cv.restore before stroke
[20:52:35] <psha> and it's working :)
[20:52:48] <psha> i've got very thick lines with fixed width
[20:54:19] <psha> cairo may be is slowest for drawing 10k lines but i think features it provides (like simple transformations) overweight this performance issue
[20:54:38] <psha> also i still don't see point in drawing all 10k samples on 1k resoultion
[20:59:21] <psha> s/cv/cr :)
[21:02:33] <psha> may be better to wrap stroke instead of path creation:
http://lists.freedesktop.org/archives/cairo/2008-June/014292.html
[21:02:40] <psha> it's from same thread
[21:36:06] <jepler> thanks, that's very informative!
[21:44:26] <jepler> weird, I wonder why cairo dropped support for the glitz back-end without a replacement
[21:46:10] <psha> i thought there was some work in opengl direction
[21:47:58] <jepler> 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
[21:50:23] <jepler> also
http://anholt.livejournal.com/42146.html
[21:51:58] <jepler> at this point it's not routinely beating xlib or image by a factor of even 5, though
[21:52:36] <psha> it's dependent on gpu i think
[21:52:49] <psha> his tests are on intel gpu which is pretty slow
[21:52:59] <psha> i think on nvidia/ati card difference will be higher
[21:53:37] <jepler> I'll run my tests again this evening on a laptop with intel integrated video
[21:57:03] <jepler> 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.
[22:00:33] <psha> for unknown reasons opengl backend is disabled in cairo debian packages
[22:02:44] <jepler> ubuntu 10.04's cairo is to old to have the new gl backend
[22:02:56] <jepler> my squeeze machine isn't available at the moment for me to check there
[22:03:12] <jepler> there also doesn't seem to be documentation on how to use that backend in
http://cairographics.org/manual/
[22:03:32] <psha> debian has 1.8 but 1.10 in experimental
[22:04:09] <jepler> 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
[22:04:35] <psha> experimental is ususally better then unstable :)
[22:19:44] <psha> at least when you try to install something it cries 'hey man, do you really want to install THAT?!"
[22:19:57] <psha> and with unstable it silently installs you tons of broken crap :)
[22:43:16] <psha> jepler: at least for me cairo-gl is not fast...
[23:00:22] <Sansiba> n8 @ll
[23:01:17] <mhaberler__> mhaberler__ is now known as mhaberler
[23:37:05] <qq-> jepler, my drawtrace
http://paste.debian.net/103046/
[23:39:45] <jepler> qq-: interesting, thanks
[23:40:04] <qq-> jepler, anytime
[23:40:16] <jepler> what opengl? software?
[23:40:28] <qq-> yes software
[23:41:39] <qq-> squeeze, on acer aspire laptop
[23:41:52] <jepler> my laptop with intel video gets 204fps gdk, 256fps glvbo, 270fps gl, 58fps cairo
[23:46:49] <jepler> hm there's a terrible memory leak in the cairo demo
[23:48:06] <jepler> well that's interesting
[23:48:23] <jepler> with the missing cairo_destroy call to fix the memory leak, it's also improved the speed
[23:50:17] <jepler> ah, no, on second thought that's not it
[23:50:40] <jepler> 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