Clarification:
"Quartz is -7% to +24% (avg. 4%) as fast as OpenGL"
should read:
"Quartz is -7% to +24% (avg. 4%) faster than OpenGL"
That is, on the 2009 Mini, the two drawing methods perform similarly
when displaying the images generated by 3D applications (bear in mind
that my application is
I've been able to optimize my code somewhat, such that it restricts
OpenGL drawing only to the changed regions of the framebuffer. That at
least made OpenGL Java 2D blitting usable for my application. However,
the Quartz Java 2D implementation under Java 6 is still much faster in
many cases. I h
Any news here Sergey?
> Am 17.02.2015 um 15:01 schrieb Sergey Bylokhov :
>
> Hello,
> Thanks for the provided info! I am able to reproduce this bug even on
> windows: gdi vs ogl. I will take a look at it.
>
> On 12.02.2015 8:28, DRC wrote:
>> On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
>>> Yo
I can't remember if I mentioned it, but in my testing (same tests as I
described below), the GDI pipeline is definitely always the fastest on
Windows. D3D is the next fastest, and OGL is the slowest. I tested on
four very different machines (2011 high-end Dell workstation with nVidia
Quadro F
> On Feb 17, 2015, at 15:01, Sergey Bylokhov wrote:
>
> Hello,
> Thanks for the provided info! I am able to reproduce this bug even on
> windows: gdi vs ogl. I will take a look at it.
This is good news.
Thanks, both of you!
I'm always appreciating a faster 2d pipeline!
-hendrik
Hello,
Thanks for the provided info! I am able to reproduce this bug even on
windows: gdi vs ogl. I will take a look at it.
On 12.02.2015 8:28, DRC wrote:
On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
You can run this test on jdk 8u31 and 8u40 to see a difference:
http://cr.openjdk.java.net/~ser
On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
You can run this test on jdk 8u31 and 8u40 to see a difference:
http://cr.openjdk.java.net/~serb/8029253/webrev.04/test/java/awt/image/DrawImage/UnmanagedDrawImagePerformance.java.html
And the test from this bug report:
https://bugs.openjdk.java.net/bro
On 10.02.2015 5:26, DRC wrote:
You're missing my point. ARGB_PRE images are faster with OpenGL but
not as fast with other blitters, so currently in order to achieve
optimal performance, my program has to somehow predict when OpenGL
blitting will be used and use an ARGB_PRE image only in those
Hello,
> On 2/9/15 10:32 AM, Sergey Bylokhov wrote:
> OK, but CreateCompatibleImage() always gives me TYPE_INT_RGB, which is>
> not optimal when using OpenGL blitting. That's why I have to go to
> the
> trouble of detecting Java 1.7-1.8 on Mac and forcing the use of a
> TYPE_INT_ARGB_PRE image
Hello,
Yes you are right, in the opengl pipeline usage of ARGB_PRE is
preferable, but other pipelines can use different formats. So it is
better to use GraphicsConfiguration.createCompatibleImage()
http://docs.oracle.com/javase/8/docs/api/java/awt/GraphicsConfiguration.html#createCompatibleImag
I discovered in my own testing that, at least for my application (which
is drawing large BufferedImages to the screen), using a
TYPE_INT_ARGB_PRE BufferedImage is in some cases 4-5x as fast as using a
TYPE_INT_RGB BufferedImage. The reason is because, if the pixel format
isn't alpha-enabled, t
On Tue, Oct 7, 2014 at 7:01 PM, Hendrik Schreiber wrote:
> On Aug 22, 2014, at 11:59, Hendrik Schreiber wrote:
>
>> On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft)
>> wrote:
>>
>> [...]
>>
>> Thanks for coming up with some sort of test.
>>
>> Hopefully the folks at Oracle find the time to
On Aug 22, 2014, at 11:59, Hendrik Schreiber wrote:
> On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft)
> wrote:
>
> [...]
>
> Thanks for coming up with some sort of test.
>
> Hopefully the folks at Oracle find the time to look into this, perhaps do
> their own performance testing, and f
Would the effect described here also affect performance of JFXPanel? I
noticed that scrolling smoothness degrades visibly when putting a tree or a
table into a JFXPanel, while the same controls scroll as smoothly as native
ones when part of a JFX stage.
Am 22.08.2014 12:10 schrieb "Hendrik Schreibe
On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft)
wrote:
> I have built a minimalistic test case that exposes the problem. It creates a
> JFrame with an editor pane in it to show some HTML content (a javadoc page).
> The test is to just scroll from the bottom to the top and back to the bott
I am wondering if this is the same issue I'm experiencing:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2014-August/006700.html
If so, it's because Java 7 and later are defaulting to OpenGL drawing on
Macs, which is slow, and there appears to be no way to change this
behavior. Java
Hi Sergey,
I have built a minimalistic test case that exposes the problem. It creates a JFrame with an editor
pane in it to show some HTML content (a javadoc page). The test is to just scroll from the bottom to
the top and back to the bottom by mouse wheel as quickly as possible, I did 5 iterat
Hi Sergey,
what a timing - while preparing for some test runs, my big screen died.
I am waiting for a replacement to arrive and will then continue with testing, but this may take
another week or so.
with best regards,
Florian
On 05.08.14 15:37, Sergey Bylokhov wrote:
Hi, Florian.
On 04.08.
Hi,
I have no test case, I can only show you our software which renders slow when
using BufferedImages and which renders fast when using VolatileImages on
JDK7/8/9.
Additionally I recently found that it renders faster when using BufferedImages
and setting property „-Dswing.volatileImageBufferE
Hi, Tobias.
Can you share the test case, which will show that a BufferedImage is not
cached using VI.
On 05.08.2014 11:32, Tobias Bley wrote:
…
So my conclusion is: JDK7 and JDK8 are not in beta stage and not finished on
Mac OS X! I don’t understand why Oracle has released it as ready….
Hop
Hi, Florian.
On 04.08.2014 19:40, Florian Bruckner (3kraft) wrote:
Are you guys aware of a performance regression from java6 on osx? Is
this something you think is worth investigating?
If yes - I can offer systematic testing on a range of different MBP
models, starting with pre-unibody MBP up
Hi,
I’m glad to see that you fetch this topic again…
I try to summarise the bug:
Starting with JDK7 Apples Quartz based rendering pipeline isn’t available
anymore. So JDK7 and higher uses the OpenGL based pipeline on MacOSX. After
hours of analysing my conclusion is that BufferedImage isn’t i
Hi,
to start with a disclaimer: I know that this list is not for end user support - I'm not looking for
support but would like to offer my help in fixing an issue with graphics performance on osx.
With java6, graphics performance was fine on my MacBook Pro Early 2011. Starting with Java7,
gra
23 matches
Mail list logo
