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
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
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
Updated the webrev : http://cr.openjdk.java.net/~prr/70299234.2/
reduces the size of the stack allocation and the incorrect else clause
Jim pointed out.
-phil.
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,
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
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
Also, perhaps gids could be stack allocated if it is small enough like
xids is in the other function?
...jim
On 3/30/2011 4:35 PM, Phil Race wrote:
Hi Clemens,
677 if ((ids = (jint *) (*env)-GetPrimitiveArrayCritical(env, gidArray,
NULL)) == NULL) {
..
688
Yeah, I thought about that too. Wasn't sure how useful it would be.
-phil.
On 3/30/2011 4:48 PM, Jim Graham wrote:
Also, perhaps gids could be stack allocated if it is small enough like
xids is in the other function?
...jim
On 3/30/2011 4:35 PM, Phil Race wrote:
Hi Clemens,
Hi Phil,
The problem was caused by the assumption that sizeof(int) ==
sizeof(XID), however Xlib uses unsigned long for XIDs, even if XIDs
are defined to be 32-bit on wire. According to the xorg mailing list
ists safe to store those values in 4-byte variables, the only case
which needs attention
Hi Clemns,
Thanks for the patch. I'll take a look shortly.
You wouldn't be the first person to be (very) surprised that the XID
type can be 64 bits
I need to look into why this didn't seem to be a problem on Solaris 11
.. I wonder how
that can be ?
BTW yes, there seems to be a known
10 matches
Mail list logo
