[OpenJDK 2D-Dev] CR 7029934 : Xrender: Text is truncated with 64 bit Linux JRE
philip.race at oracle.com
Thu Mar 31 16:26:35 PDT 2011
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.
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...
> 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.
>> 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?
>>> 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 :
>>>>> - In the 32 bit case we now avoid stack or malloc allocation -
>>>>> 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.
More information about the 2d-dev