Re: crazy gdk idea...

On Sat, 5 Jun 1999 wrote:
> 	* many Xlib implementations implement their own cacheing algorithms for GCs
> and whatnot.. so does gdk (for styles.) this extra overhead can be gotten rid
> of.
> 	* simplicity... i wont have to feel guilty for using gdk when Xlib will
> work just as well and be faster due to one less level of indirection.

This overhead is completely non-noticeable compared to the overall
overhead of talking to the X server and actually doing the drawing work -
it's not like it's the reason anything is slow. At least, I won't buy it
unless I see some profiling data. Xlib isn't exactly a high-level or thick
layer over the protocol... most of the optimizations you're describing
could be done in Xlib if they're important anyway, the Xlib source code is
there for your hacking pleasure.

Then the extra coding/maintenance work is clearly very substantial and
boring as hell - if you want to write it go nuts but the only user-visible
result is likely to be bugs. If you're actually concerned about
user-visible speed you're better off hacking X itself or optimizing the
various Gtk widgets. 


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