Re: drawing speed under Windows



> > Mabye the windows version of draw_point could cache the points, and
> > then call draw_points on a timeout when the main loop executes?
> > 
> 
> Yep I think that's pretty much the right idea. There may be tricky
> details.


when exactly did the G in gtk start standing for automa_g_ically?


first off, in cvs right now, there is draw_points. in fact, draw_point
calls draw_points with a single point. the origonal posting was asking
for draw_polygons.

if you implement the above timeout proposal with sed "s/point/polygon/g",
rather than provide a draw_polygons, it seems like you save an API prototype,
at the cost of obfuscating what is actually happening and slowing down all
draw_polygons(s) for everyone.

i'm not enough of a scientist to say without experimenting, but the timeout
seems like a non-negligible expense, and for any animation based stuff
(even at a slow 20 fps) the 10msec minimum delay (from the timeout - or
is this much quicker on windows), is significant.

it seems like draw_polygons is a reasonable abstraction, and atleast one
platform (windows) provides it natively, and only those drawables that have
it natively need to implement it, because gdkdraw.c can just fallback to
a loop of draw_polygon.

i would encourage the inclusion of such a patch if it was forthcoming and 
good quality.

seth




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]