Re: drawing speed under Windows

[Havoc Pennington <hp redhat com>]

srlytle_list yahoo com writes: 
> 
> when exactly did the G in gtk start standing for automa_g_ically?
> 

Long ago. GTK strives to save programmer thought cycles whenever
possible.

However this particular optimization is in Xlib for the X11 port, and
no one has ever accused Xlib of being too high-level.


> 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.

Sorry, I am really talking about draw_points, draw_polygons,
draw_rectangles, etc. all as the same thing.

> 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.

No. The X11 port already works exactly like this; multiple
draw_rectangle() requests get compressed into a single
draw_rectangles(). It seems to work fine for X11.

> 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.

Timeout is wrong, yes. But you can batch stuff up without using a
timeout; the X11 port already does (because Xlib does).

> 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.

draw_polygons() is not an abstraction, it's exposing an implementation
detail. The only reason to use it is efficiency, and we can trivially
get efficiency without making programmers think about draw_polygons().

Havoc