Done. And I filed
JDK-8003381: Xrender slower than X11 for filling very small (1x1) rectangles
with relevant info from the discussion.
-phil.
On 11/13/2012 4:13 PM, Phil Race wrote:
On 10/30/2012 12:35 PM, Clemens Eisserer wrote:
Hi,
Looks good to go.
Thanks =)
It would be great if somebody
On 10/30/2012 12:35 PM, Clemens Eisserer wrote:
Hi,
Looks good to go.
Thanks =)
It would be great if somebody could commit the patch, please.
I'll commit this for you.
And it would be good to file the performance issue for
small numbers of rectangles in Jira...
Has Jira been opened to the
Hi,
> Looks good to go.
Thanks =)
It would be great if somebody could commit the patch, please.
> And it would be good to file the performance issue for
> small numbers of rectangles in Jira...
Has Jira been opened to the "public" already?
Thanks, Clemens
Looks good to go. And it would be good to file the performance issue
for small numbers of rectangles in Jira...
...jim
On 10/12/2012 1:24 PM, Clemens Eisserer wrote:
Hi Jim,
One comment on code style - "if" is not a function call so the style
guidelines specify a spa
Hi Jim,
> One comment on code style - "if" is not a function call so the style
> guidelines specify a space before the parentheses with the conditional test
> (line 128 and 135).
Done.
Will keep style guidlines in mind next time.
> The logic looks fine, but I'll point out that width/height can ne
Have you done any performance testing to see if the new protections cost
any performance?
One comment on code style - "if" is not a function call so the style
guidelines specify a space before the parentheses with the conditional
test (line 128 and 135).
The logic looks fine, but I'll point
Hi Jim,
A new version of the patch is available at:
http://cr.openjdk.java.net/~ceisserer/7105461/webrev.05/
> If x or y are > MAX_SHORT then you should probably just reject the operation
> immediately, otherwise you end up with a bunch of math that should end up
> doing a NOP, but it is tenuous
Hi Clemens,
For fillRect...
If x or y are > MAX_SHORT then you should probably just reject the
operation immediately, otherwise you end up with a bunch of math that
should end up doing a NOP, but it is tenuous if it actually succeeds in
doing so.
Also, if x,y are < MIN_SHORT then when you c
Hi Jim,
Thanks for your patience, sorry this bugfix review consumed so much time.
Please find the latest webrev at
http://cr.openjdk.java.net/~ceisserer/7105461/webrev.04/
The following changes were incooperated:
- Grab AWT lock consistently before entering the try/catch block.
- Clamp X/Y to S
Hi Clemens,
Is the clip guaranteed to be rectangular here? Or is the clipping code
only meant to optimize the region of interest being processed?
In either case, I think the intersectsQuickCheckXYXY method might work
better since it does the entire test in one go and it if this code has
to
Hi Jim,
Sorry it took so long - could you please have a look at
http://cr.openjdk.java.net/~ceisserer/7105461/webrev.02
It does now protect against integer overflow, using the Region.clipAdd.
Thanks, Clemens
2012/4/17 Jim Graham :
> This code doesn't protect against integer overflow. We don't p
This code doesn't protect against integer overflow. We don't protect
against it in many places, but it couldn't hurt to get in the habit. I
think the Region code has some methods that do safe addition of integers
with simple limit clipping that would work fine for rectangle dimensions.
(JDK8
Hi,
> Looks OK to me. I'd like Jim can take a look too ..
Thanks for taking a look.
After Jim's comment for 7154083, I think it might be better to make
the bounding-box clipping unconditional in this case, as the checks
are probably more expensive than the whole clipping. I'll prepare a
second we
Looks OK to me. I'd like Jim can take a look too ..
-phil.
On 4/13/12 2:15 PM, Clemens Eisserer wrote:
Hi Phil,
Thanks for taking a look.
Fix looks reasonable and good to have a fix for this!
I do think it would be safer to be better than the X11 pipeline if possible
I reworked the original
Hi Phil,
Thanks for taking a look.
> Fix looks reasonable and good to have a fix for this!
> I do think it would be safer to be better than the X11 pipeline if possible
I reworked the original patch a bit and put the checks at a higher
level, based on the following two assumptions:
- Clippin
Hi Clemens,
Fix looks reasonable and good to have a fix for this!
I do think it would be safer to be better than the X11 pipeline if
possible ..
-phil.
On 4/13/2012 9:46 AM, Clemens Eisserer wrote:
Hi,
Please take a look at the patch for bug 7105461, located at
http://cr.openjdk.java.net/~c
Hi,
Please take a look at the patch for bug 7105461, located at
http://cr.openjdk.java.net/~ceisserer/7105461/webrev.00/
The problem was caused by Swing calling drawLine/fillRect with
coordinates outside the valid X11 coordinate space.
I took the same approach of the original X11 pipeline to simp
17 matches
Mail list logo
