Caveat - I don't have the source code for XRender handy to check, but...
Since the request does not return any data it wouldn't require a round
trip anyway, at most it would require a flush. (Note that X11 errors
are asynchronous, if a request causes an error you find out some time in
the future via a callback and they give you a request number for
reference which you were supposed to have remembered if you cared to
figure out what caused it.)
X11 typically uses a fixed sized buffer that gets autoflushed as needed.
Most requests in the core protocol are plural requests and so back to
back equivalent Xlib calls simply append their work onto the previous
request if there is still room in the buffer. When there is no more
room in the buffer, it is flushed whether or not the current request is
done (i.e. if the Xlib call refers to multiple independent pieces of
data, like XFillRectangles() then it will put as many in the buffer as
fit, flush it, and keep going until it handles all of the copies you
gave it).
Some versions of Xlib support flushing the buffer and writing the raw
buffer you hand the request back to back so that long requests can be
done in one 2-buffered chunk, though. But, those tend to be the
typically large requests like sending image data over. I'm not sure
they bother with that kind of technique for things like an
"XFillRectangles" request where the size of the rectangle list can be
easily split up and done incrementally.
So, not having seen the actual implementation I can't contradict what
you say, but historically they've used a number of techniques that would
not require it to be true. Breaking up the XRenderLib requests into
multiple calls may or may not have any effect on how many Xlib buffers
get flushed...
...jim
On 3/31/2011 3:24 PM, Phil Race wrote:
If there's any latency at all in the call to Xrender such as a server
round trip then that would be much slower, so it seems safer to
do it as it is now.
-phil.
On 3/31/2011 3:16 PM, Jim Graham wrote:
Is there a need to free all of the glyphs in a single call? Perhaps
you could just convert and free up to N at a time where N is the size
of your stack allocated array?
...jim
On 3/31/2011 1:31 PM, Phil Race wrote:
On 3/31/2011 12:07 PM, Phil Race wrote:
So .. I took the liberty of revising the fix :
http://cr.openjdk.java.net/~prr/7029934/
- In the 32 bit case we now avoid stack or malloc allocation -
basically
doing what the code was doing previously.
- In the 64 bit case we use the stack up to 256 glyphs (maybe this is
too much
as its going to be 256*8 = 1Kbytes?) and malloc above that. I could
Duh! That's 2Kbytes .. I think I'll dial this back to maybe 64 glyphs =
512 bytes
before I push.
-phil.
