So it probably is performance neutral. Is your idea that the code will be
cleaner without the malloc ?
I'd prefer not to change it again unless there's an identified benefit
and we are sure there's no downside on performance.
-phil.
On 3/31/2011 3:39 PM, Jim Graham wrote:
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.
