[OpenJDK 2D-Dev] CR 7029934 : Xrender: Text is truncated with 64 bit Linux JRE

[Jim Graham]

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