On 22.04.2014 0:16, Jim Graham wrote:
Hi Sergey,
That's a really large "worst spread" on the first and 3rd set of
benchmark results. Was the machine quiet during the benchmark run?
Yes, sure. All programs were closed, antivirus disabled, power
management was disabled too.
Since the variance
Some of the other calls are followed by resetting it to 0, but not all
(notably in that same file line 335 sets it to a potentially non-zero
value and does not reset it).
Actually, I just noticed that this one is using PACK_SKIP, but the other
cases are using UNPACK_SKIP. Still, between the t
Hi Sergey,
That's a really large "worst spread" on the first and 3rd set of
benchmark results. Was the machine quiet during the benchmark run?
Since the variance is larger than the performance gain in some cases it
might be worth getting another set of runs with a lower variance.
Also, the
Hello.
After offline discussion I found that I cannot use scanStride, and
should use width/height * pixel stride. So additional testing is required.
On 21.04.2014 18:52, Andrew Brygin wrote:
Hello Sergey,
the fast path skips j2d_glPixelStorei(GL_PACK_SKIP_ROWS, dsty).
Could you please cla
Hi, Andrew.
You are right! Actually I didn't catch this issue since I test on the
retina where all Volatile->Buffered was done via an intermediate image,
and the native blit get a zero dstX/Y.
I'll send the new version of the fix soon.
On 21.04.2014 18:52, Andrew Brygin wrote:
Hello Sergey,
Hello Sergey,
the fast path skips j2d_glPixelStorei(GL_PACK_SKIP_ROWS, dsty).
Could you please clarify why? I think that initial value of dsty
(dstInfo.bounds.y1) can be non-zero, and this operation
seem to be required...
Thanks,
Andrew
On 4/21/2014 6:17 PM, Sergey Bylokhov wrote:
Hello.
In not a reviewer, but the fix looks good to me.
I think it would be interesting to see how often you hit the slow path, I
guess it may be fairly frequent on embedded devices?
Cheers,
Mario
Il 21/apr/2014 16:18 "Sergey Bylokhov" ha
scritto:
> Hello.
> Please review the fix for jdk 9.
> This iss
Hello.
Please review the fix for jdk 9.
This issue initially was found in FX[1], and there is description of
this problem.
In the fix the flip operation is done using memcpy after the whole image
was moved from gpu to cpu.
[1] https://javafx-jira.kenai.com/browse/RT-30035
Bug: https://bugs.ope