Re: drawing speed under Windows
- From: srlytle_list yahoo com
- To: gtk-list gnome org
- Subject: Re: drawing speed under Windows
- Date: Wed, 7 Mar 2001 13:36:55 -0500
> > 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]