[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] CR 7029934 : Xrender: Text is truncated with 64 bit Linux JRE
From:       philip.race () oracle ! com (Phil Race)
Date:       2011-03-31 23:26:35
Message-ID: 4D950DAB.40607 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]