[JAVA2D] nvidia drivers - pci express running at x1 instead of 16x
Maybe it could be interesting for the java2d team too. Read it as a kind-of warning. Looks like the new 169.21 whql NVidia drivers and above (new betas) have some problems in dealing with the PCIe bus, making it run at 1x instead of 16x. This problem does not affect the previous 163.75 whql driver which runs smoothly at 16x. Is there someone here with the same performance issue ? my config Log (use the NV control panel, click on the system information text): -- NVIDIA System Information report created on: 01/14/2008 09:20:57 System name: MIK [Display] Processor: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2400 MHz) Operating System: Microsoft Windows XP (Service Pack 2) DirectX version: 9.0c GPU processor: GeForce 8600 GTS ForceWare version: 169.28 Memory: 512 MB Video BIOS version: 60.84.41.00.00 IRQ: 16 Bus: PCI Express x1 [Components] nvCpl.cpl 1.5.600.01 NVIDIA Control Panel Applet nvExpBar.dll 1.5.600.01 NVIDIA Control Panel nvCplUI.exe 1.5.600.01 NVIDIA Control Panel nvWSS.dll 6.14.11.6928 NVIDIA Workstation Server nvViTvS.dll 6.14.11.6928 NVIDIA Video and TV Server nvMoblS.dll 6.14.11.6928 NVIDIA Mobile Server NVMCTRAY.DLL 6.14.11.6928 NVIDIA Media Center Library NVOGLNT.DLL 6.14.11.6928 NVIDIA Compatible OpenGL ICD nvDispS.dll 6.14.11.6928 NVIDIA Display Server NVCPL.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver, Version 169.28 NV4_MINI.SYS 6.14.11.6928 NVIDIA Compatible Windows 2000 Miniport Driver, Version 169.28 NV4_DISP.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver, Version 169.28 nvGameS.dll 6.14.11.6928 NVIDIA 3D Settings Server -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] nvidia drivers - pci express running at x1 instead of 16x
A little followup: after testing new and beta drivers with no luck, I decided to install a different board: NV7600GT without changing the drivers. The NV7600GT worked very well at x16 speed and the new drivers (169.21) were ok. I removed the NV7600 and installed the NV8600GTX and this time was running at 16x as expected. All ok ? Not completely: the drivers 169.21 for sure give different onscreeen performance, comparing with the previous 163.75. They are roughly 65% slower. Anyway I achieve the same speed when testing in-memory read-write benchmarks: 1.7GB/s write, 1.0GB/s read. For onscreen I mean - compute some graphics (with opengl), make an argb bufferedimage, paint onscreen (jpanel). My guess is that Nvidia changed something in the screen updating code. This is jdk independent: jdk 1.5.x and jdk 1.6.0_04 give the same results. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] D3D pipeline on Geforce-FX5200
Not so wrong... I would like to know if someone has tested the new 169.21 whql NVidia drivers too. They appear to be very slow in handling offscreen graphics (pbuffers), compared with the previous 163.75. Cheers, Mik -- - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 22, 2007 6:55 AM Subject: Re: [JAVA2D] D3D pipeline on Geforce-FX5200 duh! Replied to the wrong message. Dmitri [Message sent by forum member 'trembovetski' (trembovetski)] http://forums.java.net/jive/thread.jspa?messageID=251213 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] D3D pipeline on Geforce-FX5200
A bit off-topic, maybe, but as I'm experiencing a serious performance issue with the new 169.21 whql NVidia drivers, I would share some info here. The rendering speed of my RGBA pbuffers draw and readback demo is falling down from 850fps to 300 fps, compared with the previous 163.75 whql driver (-65%). Config: WinXP, Intel DP35DP, Q6600 @ 2.4ghz, 2GB ram, NV8600GTS. Is there someone here with the same performance issue ? -- - Original Message - From: Dmitri Trembovetski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 20, 2007 6:26 PM Subject: Re: [JAVA2D] D3D pipeline on Geforce-FX5200 Thanks a lot for the report, of course it is useful. I have a FX5200 board here and it doesn't have an of these issues. It's not the fastest board around, for sure, but I haven't seen rendering artifacts you're describing. Could you try installing the latest driver from nvidia.com and see if it helps? The latest version is 169.21 and you have 163.16. I'll file a bug anyway so that we can track this. We'll likely need to only enable the pipeline if the driver is known to be ok. Thanks, Dmitri === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Font kerning/spacing issues ?
Hello all at Java2D, please take a look at this picture: www.classx.it/public/font2dtest.jpg the first LATIN text is rendered with Java2d (1.5, 1.6, winxp) the second is rendered with CorelDraw (but I get the same result with any other gfx program). You can notice an abnormal spacing between the A and the T glyphs in the java version. The CorelDraw version looks more correct, IMHO. I've tested many other fonts but I always got the same results. Where's the problem with java2d font rendering ? Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Font kerning/spacing issues ?
Phil, David, many thanks for your help. Phil, you say thay the KERNING hint is not there by default because: 1) changes the overall text length 2) requires extra processing steps at rendering time. Do you mean that I may also encounter performance or compatibility issues ? Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders
- Original Message - From: Chris Campbell [EMAIL PROTECTED] To: Michele Puccini [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 4:48 AM Subject: Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders Hi Chris, thanks for this followup. It's always a pleasure to read your posts. There's one minor problem with the testcase: the call to Toolkit.sync() needs to come right after computeImage(), not before it. I didn't know what Toolkit.sync() does. The test code is a customized version of something found around. Thanks for the hint. Writing accurate microbenchmarks can be a tricky business. Agreed 100%. You know this was a silly stability case with some little benchmarking aims in mind. It was not my aim to measure the speed of random() ;) Anyway I'm convinced that microbenchmarks are not the only solution for getting a picture of how the things are working. Maybe sometimes you also need to spend some cpu time in doing real-world benchmark code. I know your car can go at 300Km/h, but did you see the holes in the road ? ;) Also, when you're rendering to a BufferedImage (or compatible image), you're only measuring the performance of software loops, not the OGL pipeline. To measure performance of the OGL pipeline, you have to render to a VolatileImage. And what about managed images i.e. the capability to auto-accelerate BufferedImages etc. ? According to what I read on this link: http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a_1.html if you want to take advantage of possible acceleration for your image, use a compatible image I was hoping to get some sort of auto-acceleration from createCompatibleImage(). This doesn't seem to be the case. Lack of knowledge from my side ? Mmmh. this is an important point for the java2d community. There's a position from Jerry Huxtable about managed images here. http://www.jhlabs.com/ip/managed_images.html This is also an important point for the low-level java2d community. Sometimes I get a crash into NVOpenGLPbuffer.exe. Sometimes it silently dies. This is the driver bug I alluded to earlier in 93.71. This bug is fixed in Nvidia's next release, but it has been extremely frustrating waiting for them to release that new driver (3 months is way too long between releases)! Until that's released, you can work around the problem by adding the following to the command line: -Dsun.java2d.opengl.fbobject=false Yes, I added this line some tests ago. Turning off the FBObject seems to fix the problem and the jframe repaints correctly, but the speed [VolatileImage] is at software levels both for AA and not-AA lines. Bad news. When the FBObject is on: [VolatileImage] without AA the benchmark time is very low (fast!), but it does repaint nothing. with AA the benchmark time is very-very high and still it does repaint nothing. In both cases the jframe does not repaint itself anymore after the first run. Trying to resize the jframe brings to a crash of NVOpenGLPBuffer. -- Unhandled exception at 0x69665851 in javaw.exe: 0xC005: Access violation reading location 0x0014. nvoglnt.dll!69665851() [Frames below may be incorrect and/or missing, no symbols loaded for nvoglnt.dll] nvoglnt.dll!69665983() nvoglnt.dll!69706018() kernel32.dll!7c80b683() -- On the couple Nvidia configurations I tried, I got similar performance results to what I saw on ATI when rendering to a VolatileImage (more details below). I would expect OGL to be a win for non-AA diagonal lines, and maybe a bit slower for AA diagonal lines. Currently it is more than a bit. - Config 2 - WinXP sp2, P4 3.2Ghz HT, 2GB ram, ATI X1600 (drivers catalyst 6.12), jdk 1.5.1_11, jdk 1.6.0 fcs. on jdk6, volatileimage or compatibleimage, antialias on or off, ogl on: Test frame repaint is broken: does not always repaint. Could you elaborate on this? How is it broken? On our desktops we use solid window dragging, i.e. you see the contents of the window while moving/resizing it. If I drag the test window outside the screen and then inside, its contents are not repainted correctly. Dragging the window across the screen borders I can see the lines test image repainting at wrong offsets like it is sliding inside the contentpane. The test works and I see the lines, even when running multiple times. BIG suprise! Using the volatileimage path I get the real OpenGL speed (but the antialias must be off)! Here's what I see on my machine with ATI Radeon 9800 Pro, 2x 2.8GHz P4 (rendering to VolImg using J2DBench): def: 547.1678467 (var=0.67%) (100.0%) ogl: 542.0107349 (var=0.0%) (99.06%) As you can see, there's not much benefit for AA lines, but for non-AA lines OGL is about 50x faster than the default I see.. Note that the numbers for AA lines still look pretty bad for OGL when compared to non-AA. We
Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders
Hi Chris, that's fantastic news indeed. I'll check the new jdk7 as soon as b10 is released. While waiting for your blogs, I have a story for you. Some time ago I was forced to use LWJGL in order to write an OpenGL/Graphics2D wrapper (not as complete as the real thing, but it works very well for images, clipping, some kind of vectors). That's why when I started with the java2d-ogl it was too fresh to be stable and fast. It was jdk 1.4.x time, if I don't mistake. Then time passed and now we have jdk6 (and this is GOOD). Sadly all my experiments to update my code in order to take advantage of the new jav2d-ogl failed again because of the number of crashes or unexpected behaviors experienced even with very simple test code. Driver issues, one might say. Bad test code ? Not likely, maybe... But it's all very discouraging for me. By the time I'm writing this email I'm also testing some deeply-raw-five-min-dev-time code in order to see how the jav2d-ogl impacts the speed of antialiased drawLine()s. - The test itself hangs on jdk6 but runs on jdk5. - I see no speed increases by turning on/off opengl. - I usually get a crash in NVOpenGLPbuffer on jdk6 when resizing the jframe. Other problem: when I turn on sun.java2d.opengl also the gui becomes accelerated, but this could also be the source of repaint problems and other odd driver/config dependent issues. Result: I can't ship my apps with opengl enabled by default. I would opt for the possibility to have the choiche to not accelerate Swing. So, jav2d-ogl is a wicked good idea. We all wanted it. But.. how can I make real-world use of it ? Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Chris Campbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 22, 2007 6:46 PM Subject: Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders Hi Mik, On Feb 22, 2007, at 2:11 AM, Michele Puccini wrote: A little followup.. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] java2d Compositing - OpenGL fragment shaders
- Original Message - From: Michele Puccini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 7:41 PM Subject: java2d Compositing - OpenGL fragment shaders A little followup.. the fragment shader code of my previous email was bloody wrong as the docs say: Notice that the fragment shader has no access to the frame buffer. This implies that operations such as blending occur only after the fragment shader has run. The big mistake is that I was thinking of reading the framebuffer contents with gl_FragColor.. :( Mmmh.. maybe I could implement my blending by binding a pbuffer object to a texture (or even a FBO) and then access the dest pixels from there, right ? But, anyway, the idea of using shaders in the java2d/opengl codepath could still be valid. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] java2d Compositing - OpenGL fragment shaders
Hello all at java2d,
Hello Chris,
after bouncing my head for some time over OpenGL, alpha compositing,
accumulated and premultiplied alpha I decided (curiosity) to take a look at
the j2se6 source code just to see what happens behind the scenes.
All I discovered (surprise ?) is that the OpenGL codepath of java2d has to
deal with premultiplied alpha pixels. That's probably because the Porter and
Duff compositing rules work better with premultiplied data ;)
But premultiplying and unpremultiplying is done in software loops, so this
generates some overhead, expecially when using java2d for creating offscreen
graphics with unpremultiplied images (me).
So I decided to implement my very first OpenGL fragment shader that does a
SRC_OVER composite on unpremultiplied data. I'm a true beginer, so please
forgive me.
Here's the code
-
uniform sampler2D texture;
void main()
{
vec4 s = texture2D(texture,gl_TexCoord[0].st);
vec4 d = gl_FragColor;
float extra_alpha = 0.1;
s.a = s.a * extra_alpha;
if (s.a == 0.0) gl_FragColor = d;
else if (s.a == 1.0) gl_FragColor = s;
else if (d.a == 0.0) {gl_FragColor = s;}
else
{
float a = s.a + d.a - s.a * d.a;
gl_FragColor.a = a;
gl_FragColor.r = (s.a*s.r+d.a*d.r-s.a*d.a*d.r)/a;
gl_FragColor.g = (s.a*s.g+d.a*d.g-s.a*d.a*d.g)/a;
gl_FragColor.b = (s.a*s.b+d.a*d.b-s.a*d.a*d.b)/a;
}
}
-
I works very well and, apart that compiler warning (!), the results are 1:1
the SRC_OVER I get from the Java2D software loops.
So the question: why don't implement the entire OpenGL java2d Composite with
fragment shaders and avoid premultiplied data ?
Cheers!
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders
Hi Mike,
of course the main aim is always speed, speed, speed.
Your question about speed gains is quite crucial and the answer may be of
course very complicated to elaborate. Just mix up some aspects:
implementation
- how can shaders be implemented in java2d-ogl ?
- what can be affected from the implemention ?
- which gfx ops can benefit from shaders implementation ?
- can we really avoid software loops in any case ?
- add here..
application
- what kind of application am I developing
- how can I get the most out of the new hava2d implementation
- is it true that a faster graphics operation may speedup the whole
application ?
- add here..
hardware implementation
- are shaders implemented in my hardware ?
- which is their speed (n. of onboard shaders, pipeline implementation, gpu
speed, mem speed,..) ?
- are there any compatibility issues from gpu to gpu / driver to driver ?
- add here..
Well, given the current and future graphics hardware implementation, the use of
shaders will definitely boost java2d speeds in many ways, from advanced
compositing to bufferedimage ops, to convolves.
Cheers,
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
- Original Message -
From: Michael Toula
To: [EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 12:27 PM
Subject: Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders
Michele,
I guess the reason why you implement it using a fragment shader is to see a
speed increase.
What speed increase can we expect using your technique (What CPU/Graphic card
are you using) ?
I was thinking of implementing something similar for BufferedImageOp ( speed
up ConvolveOp for exemple ), so I'm interested in your results.
On a side note, not everybody has a fragment shader capable graphic
card/OpenGL driver.
Best,
Mike
**
Michael TOULA
Software Engineer
Dalim Software GmbH
Strassburger Str. 6
D-77694
Kehl am Rhein
GERMANY
tel: +49 7851 919 612
fax: +49 7851 735 76
web: www.dalim.com
**
Michele Puccini [EMAIL PROTECTED]
Sent by: Discussion list for Java 2D API [EMAIL PROTECTED]
22/02/07 11:20 Please respond to
Michele Puccini [EMAIL PROTECTED]
To [EMAIL PROTECTED]
cc
Subject [JAVA2D] java2d Compositing - OpenGL fragment shaders
Hello all at java2d,
Hello Chris,
after bouncing my head for some time over OpenGL, alpha compositing,
accumulated and premultiplied alpha I decided (curiosity) to take a look at
the j2se6 source code just to see what happens behind the scenes.
All I discovered (surprise ?) is that the OpenGL codepath of java2d has to
deal with premultiplied alpha pixels. That's probably because the Porter and
Duff compositing rules work better with premultiplied data ;)
But premultiplying and unpremultiplying is done in software loops, so this
generates some overhead, expecially when using java2d for creating offscreen
graphics with unpremultiplied images (me).
So I decided to implement my very first OpenGL fragment shader that does a
SRC_OVER composite on unpremultiplied data. I'm a true beginer, so please
forgive me.
Here's the code
-
uniform sampler2D texture;
void main()
{
vec4 s = texture2D(texture,gl_TexCoord[0].st);
vec4 d = gl_FragColor;
float extra_alpha = 0.1;
s.a = s.a * extra_alpha;
if (s.a == 0.0) gl_FragColor = d;
else if (s.a == 1.0) gl_FragColor = s;
else if (d.a == 0.0) {gl_FragColor = s;}
else
{
float a = s.a + d.a - s.a * d.a;
gl_FragColor.a = a;
gl_FragColor.r = (s.a*s.r+d.a*d.r-s.a*d.a*d.r)/a;
gl_FragColor.g = (s.a*s.g+d.a*d.g-s.a*d.a*d.g)/a;
gl_FragColor.b = (s.a*s.b+d.a*d.b-s.a*d.a*d.b)/a;
}
}
-
I works very well and, apart that compiler warning (!), the results are 1:1
the SRC_OVER I get from the Java2D software loops.
So the question: why don't implement the entire OpenGL java2d Composite with
fragment shaders and avoid premultiplied data ?
Cheers!
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST
Re: [JAVA2D] PID in sun.awt.image.PNGImageDecoder.produceImage()
Thanks Dmitri, Phil, I was unable to replicate the bug on my development machine but it happened quite often on two customer's machines (I was there) which indeed are very similar to mine (same chipset, processor, clock). Here's the main config differences I remember: I'm on WinXPHE and the customer has WinXPPRO. Memory: 2GB for me and 4GB for the customer. VMem: enabled for me and disabled for the customer. The java startup config is the same on all machines. I've tried on my machine with jdk6 and everything worked. Sadly I'm not able to test on the customer machine as he is so far from my office now. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Phil Race [EMAIL PROTECTED] To: Michele Puccini [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 8:48 PM Subject: Re: [JAVA2D] PID in sun.awt.image.PNGImageDecoder.produceImage() yes that is what it looks like. Current CompileTask: HotSpot Client Compiler: 38 !b sun.awt.image.PNGImageDecoder.produceImage()V (1772 bytes) There's an 'XX' option to java which tells hotspot not to compile a specific method. I think the syntax is : -XX:CompileCommand=exclude,sun.awt.image.PNGImageDecoder.produceImage If that helps then its very probably a compiler bug If not someone in the VM forums may be able to give you more ways to diagnose if its really a VM problem or just looks like it -phil. Dmitri Trembovetski wrote: Hi Mik, the crash happened in hotspot (on their compiler thread), not in the libraries, so it's hard to say what could be wrong. Could you try your applicaion on jdk6? Thanks, Dmitri On Wed, Nov 22, 2006 at 01:06:07PM +0100, Michele Puccini wrote: Hello, I'm getting the following PID when decoding PNG files. The PNG decoding is called from an under pressure rendering thread. The crash does not happen if we use our internal (all Java) PNG or TGA readers. What happens ? Cheers, Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] PID in sun.awt.image.PNGImageDecoder.produceImage()
Hello, I'm getting the following PID when decoding PNG files. The PNG decoding is called from an under pressure rendering thread. The crash does not happen if we use our internal (all Java) PNG or TGA readers. What happens ? Cheers, Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. hs_err_pid808.log Description: Binary data
Re: [JAVA2D] AttributedString and Outline (the return of the glyph invaders!)
Phil, so, correct me if I'm wrong, the TextLayout.draw() rasterizes every single glyph (and its TextAttributes) to separate images before drawing them to the Graphics ? I can understand the complexity behind glyphs, fonts, graphics and text, but .. is there a specific reason why we need to align to the pixel grid ? Maybe we would get the same features of the Texlayout by rasterizing outlines and effects straight to the Graphics and getting sub-pixel precision. Maybe not. Now it's your turn ;) Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Phil Race [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 16, 2006 10:36 PM Subject: Re: [JAVA2D] AttributedString and Outline (the return of the glyph invaders!) First, its not a bug in TextLayout drawString behaves identically. You can prove this as follows, instead of your AttributedString use Font fo = new Font(Serif, Font.PLAIN, 12); fo = fo.deriveFont(AffineTransform.getScaleInstance(2 + scale, 3)); g.setColor(Color.white); g.setFont(fo); g2d.drawString(text, x, y); Second, text does not scale linearly because of the same hinting and gridfitting effects I described earlier, and the glyphs are fitted to the pixel grid and you are specifying fractional point sizes. FRACTIONAL_METRICS is being specified but that affects only the accumulation of the advance. It doesn't change the images. You'd probably see a similar effect with the outline if you disabled FRACTIONAL_METRICS. -phil. Michele Puccini wrote: Thanks Phil, I did a little mistake: is not a problem of the outline, which is indeed correct. Well, a piece of code is worth a thousand words. The attached sample shows the animated difference between TextLayout.draw() and g2d.draw(TextLayout.getOutline). Please give it a try and see what happens. Is is quite funny to see the glyphs in the first line jumping one pixel to the other just like the space invaders in that old arcade game ;) As you will see from the animation, the glyphs rendered with TextLayout.draw() jump from one pixel to the other (at int coords ?), while the glyph outlines are rendered with the expected quality. Funny enough, the red cursor on the C letter is rendered at float coords. So, in my opinion, TextLayout.draw() does not give the expected quality resuls and this is a pity as it really is very useful. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] AttributedString and Outline (the return of the glyph invaders!)
Thanks Phil, I did a little mistake: is not a problem of the outline, which is indeed correct. Well, a piece of code is worth a thousand words. The attached sample shows the animated difference between TextLayout.draw() and g2d.draw(TextLayout.getOutline). Please give it a try and see what happens. Is is quite funny to see the glyphs in the first line jumping one pixel to the other just like the space invaders in that old arcade game ;) As you will see from the animation, the glyphs rendered with TextLayout.draw() jump from one pixel to the other (at int coords ?), while the glyph outlines are rendered with the expected quality. Funny enough, the red cursor on the C letter is rendered at float coords. So, in my opinion, TextLayout.draw() does not give the expected quality resuls and this is a pity as it really is very useful. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Phil Race [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 16, 2006 1:08 AM Subject: Re: [JAVA2D] AttributedString and Outline The bitmap glyph images are hinted and gridfitted. This is not done for the returned outline as it doesn't make sense to do that for a pure shape. For most of what you are doing you need outlines anyway as the rasteriser can only return glyph images. -phil. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. AttributedStringTest.java Description: Binary data
Re: [JAVA2D] Gray Rect fix of Java2 SE 6
Hi Chris,
I'm back to the office and I keep with my tests. All I can say for the
moment is that I'm testing on a WinXP machine with 2GB ram, P945D, NVidia
Geforce 6600GT 128MB (drivers 93.71).
The OpenGL or D3D pipelines are off.
By enabling OpenGL I always get a bad crash in NVOpenGLPbuffer after the
first application splash screen opens.
Of course I can send you the test application if you have time to do your
tests.
Cheers,
Mik
--
- Original Message -
From: Chris Campbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 4:08 AM
Subject: Re: [JAVA2D] Gray Rect fix of Java2 SE 6
Hi Mik,
Thanks for the update. It would be great if you could continue to
narrow down the problem and let us know what you find, since it sounds
like it could be a 2D-specific problem.
You didn't mention which platform you're running on, graphics card,
driver version, etc. Also, do you have the D3D or OGL pipeline enabled
by any chance?
Thanks,
Chris
Michele Puccini wrote:
Thanks Chris,
sadly the trick didn't work for me. The problem is still here, even when
disabling double buffering.
The GUI is extremely responsive with Java2SE 5.x but not with the new
Java2SE 6 RC.
This happens when the application is involved in some heavy graphics
computation (40% cpu, multiple threads drawing graphics, etc.).
Maybe it's a threading priority problem. I don't know. I'm on a P4 dual.
I was thinking about a side effect of the new gray rect fix, but it's
not.
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte
(PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB:
http://www.classx.it
- Original Message -
From: Chris Campbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 13, 2006 5:58 PM
Subject: Re: [JAVA2D] Gray Rect fix of Java2 SE 6
Hi Mik,
There's no official way to disable the gray-rect fix, but here's a
simple way to do it: install a trivial RepaintManager. This will revert
to the JDK 5 behavior, which might help you figure out if the gray-rect
fix is related to your performance issues. Let us know what you find.
For example:
class MyRepaintManager extends RepaintManager {}
RepaintManager.setCurrentManager(new MyRepaintManager());
Thanks,
Chris
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST. For general help, send email
to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] AttributedString and Outline
Thanks Chris, but again I would like to put the stress on the fact that: TextLayout.draw(..); gives very different results from g2d.draw(TextLayout.getOutline(..)); While the first one works very well, the second one gives different visual results and the character shapes are badly spaced. It looks like they're aligned to int coords. Please run the OutlineTest.java for a quick look. That's the main reason why I can't overlay TextLayout.draw(..) over a TextLayout.getOutline() without getting spurious pixels around the characters. Can you investigate ? Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Chris Campbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 13, 2006 4:52 PM Subject: Re: [JAVA2D] AttributedString and Outline Hi Mik, You might also be able to glean some ideas from the SwingLabs team's recent work on Painters. The basic approach is to paint text as an outline (and shapes, images, etc) and then perform various effects on each layer, for example: http://weblogs.java.net/blog/joshy/archive/2006/09/introducing_pai_1.html Chris Phil Race wrote: Vincent Hardy's book Java 2D API Graphics comes with a GLF toolkit which supports many effects. There are examples of embossed text and other effects. I believe the toolkit is available for download. Use your favourite search engine. You can also take a look at the java 2D demo. This does use outlines. Sounds like that isn't exactly what you want but take a look anyway Also note that you can set FOREGROUND and BACKGROUND text attributes which can be a Paint, not just a Color. -phil. Michele Puccini wrote: Hello, I'm using TextLayouts made by AttributedStrings and I need to outline (Stroke) the characters. Sadly I didn't find any Outline TextAttribute, so I would like to know how to implement it. More generally it would be nice to implement virtually any kind of TextAttribute i.e. Emboss, Shadow, etc. Suggestions ? Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Gray Rect fix of Java2 SE 6
Thanks Chris,
sadly the trick didn't work for me. The problem is still here, even when
disabling double buffering.
The GUI is extremely responsive with Java2SE 5.x but not with the new
Java2SE 6 RC.
This happens when the application is involved in some heavy graphics
computation (40% cpu, multiple threads drawing graphics, etc.).
Maybe it's a threading priority problem. I don't know. I'm on a P4 dual.
I was thinking about a side effect of the new gray rect fix, but it's not.
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
- Original Message -
From: Chris Campbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 13, 2006 5:58 PM
Subject: Re: [JAVA2D] Gray Rect fix of Java2 SE 6
Hi Mik,
There's no official way to disable the gray-rect fix, but here's a
simple way to do it: install a trivial RepaintManager. This will revert
to the JDK 5 behavior, which might help you figure out if the gray-rect
fix is related to your performance issues. Let us know what you find.
For example:
class MyRepaintManager extends RepaintManager {}
RepaintManager.setCurrentManager(new MyRepaintManager());
Thanks,
Chris
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] AttributedString and Outline
Hello, I'm using TextLayouts made by AttributedStrings and I need to outline (Stroke) the characters. Sadly I didn't find any Outline TextAttribute, so I would like to know how to implement it. More generally it would be nice to implement virtually any kind of TextAttribute i.e. Emboss, Shadow, etc. Suggestions ? Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Gray Rect fix of Java2 SE 6
I'm facing some graphics performance issues by running my apps on Java2SE 6, never experienced on Java2SE 5. Is possible to temporarily disable the Gray Rect fix (I have some suspects) ? Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] KEY_STROKE_CONTROL, thanks
Hi Jim, thank you for the KEY_STROKE_CONTROL hint, which saved me from getting poor stroking/positioning quality expecially with small fonts. I think that this hint should be publicized a little more. I suppose that when KEY_STROKE_CONTROL is set to VALUE_STROKE_PURE it doesn't affect the performance of Java2D. Can you confirm this ? Cheers, Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] 1.6.0-beta-b59g ogl crash
Here's the dump. It happened after playing a while with Castalia using the new jdk1.6.0 beta, ogl on. No probs when ogl is off. Config: WinXP sp2, 1GB ram, NVidia geforce 6600 (128MB, pci express, drv 81.98). Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d90c6b1, pid=2840, tid=2356 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-beta-b59g mixed mode, sharing) # Problematic frame: # V [jvm.dll+0xcc6b1] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x036b1e00): JavaThread Java2D Queue Flusher daemon [_thread_in_vm, id=2356] siginfo: ExceptionCode=0xc005, reading address 0x0004 Registers: EAX=0x, EBX=0x036b1e00, ECX=0x2c7d18a0, EDX=0x0001 ESP=0x03a7fa08, EBP=0x03a7fa24, ESI=0x, EDI=0x2c807858 EIP=0x6d90c6b1, EFLAGS=0x00010246 Top of Stack: (sp=0x03a7fa08) 0x03a7fa08: 2c807858 03a7fa90 036b1ee4 036b1e00 0x03a7fa18: 03a7f978 036b1ee4 0x03a7fa28: 6d048ea7 0001 2c7d18a0 0x03a7fa38: 0240 03a7fb08 0x03a7fa48: 6d0de1da 036b1ee4 2c807858 03a7fa90 0x03a7fa58: 036aa098 02d0 698ddea0 0x03a7fa68: 0240 02d0 40868000 0x03a7fa78: 80e1 8367 0004 0101 Instructions: (pc=0x6d90c6b1) 0x6d90c6a1: 89 93 44 01 00 00 74 03 c6 00 00 8b 4d 0c 8b 31 0x6d90c6b1: 8b 46 04 8b 50 08 8d 48 08 ff 92 80 00 00 00 84 Stack: [0x0398,0x03a8), sp=0x03a7fa08, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xcc6b1] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J sun.java2d.opengl.OGLRenderQueue.flushBuffer(JI)V J sun.java2d.opengl.OGLRenderQueue.flushBuffer()V J sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run()V v ~StubRoutines::call_stub --- P R O C E S S --- Java Threads: ( = current thread ) 0x2c8fc900 JavaThread ObjectPool-CleanUp (ImagePool) [_thread_blocked, id=2820] 0x0385e500 JavaThread TimerQueue daemon [_thread_blocked, id=2504] 0x0385e100 JavaThread ObjectPool-CleanUp (PathPool) [_thread_blocked, id=2648] 0x2c706a00 JavaThread CommandMaster (AVIManager) [_thread_blocked, id=2952] 0x2c6f7500 JavaThread ObjectPool-CleanUp (CursorPool) [_thread_blocked, id=3120] 0x037d5c00 JavaThread Thread-28 [_thread_in_native, id=2248] 0x037b2700 JavaThread AWT-EventQueue-0 [_thread_blocked, id=236] 0x03773d00 JavaThread ObjectPool-CleanUp (SGLImagePool) [_thread_blocked, id=1248] 0x0375bb00 JavaThread CommandMasterAsynch (SGLMaster) [_thread_blocked, id=368] 0x03678700 JavaThread AWT-Windows daemon [_thread_in_native, id=164] 0x03677900 JavaThread AWT-Shutdown [_thread_blocked, id=3996] =0x036b1e00 JavaThread Java2D Queue Flusher daemon [_thread_in_vm, id=2356] 0x03672400 JavaThread Java2D Disposer daemon [_thread_blocked, id=3704] 0x02dfa000 JavaThread Low Memory Detector daemon [_thread_blocked, id=2812] 0x02df7b00 JavaThread CompilerThread0 daemon [_thread_blocked, id=2972] 0x02df6c00 JavaThread Attach Listener daemon [_thread_blocked, id=1484] 0x02df6000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=1480] 0x02dee800 JavaThread Finalizer daemon [_thread_blocked, id=3060] 0x02deda00 JavaThread Reference Handler daemon [_thread_blocked, id=244] 0x00a07300 JavaThread main [_thread_blocked, id=1748] Other Threads: 0x02deca00 VMThread [id=2168] 0x02e03f00 WatcherThread [id=3364] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 9664K, used 432K [0x05b4, 0x065b, 0x083b) eden space 8640K, 0% used [0x05b4, 0x05b46d50, 0x063b) from space 1024K, 39% used [0x064b, 0x06515320, 0x065b) to space 1024K, 0% used [0x063b, 0x063b, 0x064b) tenured generation total 127664K, used 92972K [0x083b, 0x1005c000, 0x2694) the space 127664K, 72% used [0x083b, 0x0de7b0a0, 0x0de7b200, 0x1005c000) compacting perm gen total 12288K, used 7240K [0x2694, 0x2754, 0x2a94) the space 12288K, 58% used [0x2694, 0x27052010, 0x27052200, 0x2754) ro space 8192K, 62% used [0x2a94, 0x2ae47d88, 0x2ae47e00, 0x2b14) rw space 12288K, 55% used [0x2b14, 0x2b7f4368, 0x2b7f4400, 0x2bd4) Dynamic libraries: 0x0040 - 0x0042d000 C:\Programmi\ClassX\castaliacg\CastaliaCG.exe 0x7c91 - 0x7c9c6000 C:\WINDOWS\system32\ntdll.dll 0x7c80 - 0x7c8ff000 C:\WINDOWS\system32\kernel32.dll
Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Chet,
as you guessed I need the handle to the window in order to determine the
device (monitor) I'm using. Different devices may have different refresh
rates. In my case I have the main monitor at 75Hz and the PAL second monitor
at 50Hz.
Here I construct a ddraw object using the native window handle of the java
canvas (using jawt).
// init
DDrawPtr = DirectDrawCreateFromWindow(hWnd);
hMonitor = OneMonitorFromWindow(hWnd);
if (hMonitor != NULL)
{
MonitorInfo.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(hMonitor,MonitorInfo);
}
// then I call
videoutils.waitvbl() from the java side. I don't have any native paint code.
Working without JAWT can make life simpler. Can you post some code ?
Maybe you may want to take a look at my code. Just ask for it.
Mik
--
- Original Message -
From: Chet Haase [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 30, 2006 3:37 PM
Subject: Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Note that you may be able to get away with vsync'ing without
JAWT; vsync is done on a per-device basis and does not need a
handle to the window. The main reason you'd need to know the
window would be to determine the correct device (display) to
use. If you can determine that some other way, then you
can skip JAWT altogether and just call the appropriate
vsync operation on the correct device.
(I just tried this experiment on an unrelated project and
it seemed to work - I init a separate ddraw object at startup
time and then call into JNI to call ddraw's WaitForVerticalBlank
function in my paint method. Works like a charm).
Chet.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Dmitri, I've managed to create a simple class (VideoUtils) that implements Vertical Blanking synchronization with multimonitor support through directdraw calls in a separate jni dll. Note: the jawt.dll is delayloaded from my jni implementation. Anyway I have a strange runtime problem with JAWT: - if the class extends java.awt.Canvas then it can load and initialize JAWT and everything works. - if it doesn't, JAWT will not be loaded I get an error java.lang.UnsatisfiedLinkError: C:\Programmi\Java\jdk1.5.0_06\jre\bin\jawt.dll: Can't find dependent libraries at clinit. The class is an helper class and should not be Canvas. Thanks, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Dmitri Trembovetski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 5:52 PM Subject: Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking I realize that. What I'm saying is that since a Vsynched windowed buffer strategy would be implemented in the same way the FlipBufferStrategy is, there won't be a problem with the cpu usage. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Hi Dmitri,
As long as you're there and you'll implementing this anyway, why not
try to implement it for the jdk? You can join the mustang
development community:
http://mustang.dev.java.net
It'd take a while to setup the build environment, but I can point
you to the right blogs and such..
I'll give it a look. Of course I have to fully implement my in-house stable
version first.
Feel free to send me links or whatever you feel it could be interesting for
me.
RFE: It would be nice to have a .show(boolean VSynch) in java2d. The
main
problem is the CPU load: the caller waits until it gets the vsynch. The
implementation could setup an event and be signalled when the vsynch
arrives.
Well, the users don't complain about this for the full-screen
BufferStrategy (aka FlipBufferStrategy).
FlipBufferStrategy is already VSynched. BlitBufferStrategy is not. That's
the case I would like to address.
I don't think asynchronous vsync event is a good idea, though, as it
typically turns out to be too much hassle and potential
multithreading issues.
Yes. I try to explain better (oofff). Using a brute-force approach {while
!vblank();} leads to a high CPU load. This could be avoided by sleeping
the waiting thread for a moment (some ms for each loop). The dshow
implementation can signal an event. This means that we could be simply
wait() until signalled.
There's a nice article here - http://www.compuphase.com/vretrace.htm
Hmm. I don't see why it wouldn't work.
Do you use BufferStrategy with the same canvas? Could your
rendering be overwritten by the contents of the back-buffer?
Could you try running your app with ddraw disabled
(-Dsun.java2d.noddraw=true)?
Also, do you add your canvas before or after entering the
full-screen mode? We do some funny stuff under the covers when
entering the full-screen mode (especially if you're using Window
instead of Frame to enter the FS mode).
At the moment I'm not going to spent too much time here as it would be a
very implementation-specific topic.
Even more the fullscreen exclusive mode is not suited for the kind of app
we're going to produce (the auto-iconify is too much dangerous in the case
you count on a 24h/24h full screen output).
Anyway I'll take some time to investigate further
with -Dsun.java2d.noddraw=true and let you know.
Cheers!
Mik
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI)
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] FullScreen, BufferStrategy, Vertical Blanking
Hello everybody, I've done some experiments with both FullScreen exclusive mode and BufferStrategy and I have some questions (win32): 1) Imagine a dual monitor application, the main monitor for the GUI and the second for the fullscreen preview. Why the fullscreen preview iconifies automatically when I select window different from my app window or when another window gets the focus ? When this happens I have to manually re-select (ALT-TAB) the preview window in order to show it again. 2) The same dual monitor application does not suffer of the auto-iconify feature if I don't use the FullScreen API (i.e. setFullScreenWindow(null)), but the output doesn't seem to be synched to the Vertical Blanking as expected. How can I get a BufferStrategy window that is vsynched to the frequency of the screen it uses ? 3) Maybe too much win32-specific and a bit offtopic, but maybe of some interest for the group. I've created a MediaPlayerCanvas using JNI,COM and the VMR9 Video Mixing Renderer Filter. It works really well with any kind of media, but it doesn't display on a FullScreen window. Maybe Exclusive mode means something.. Anyway I always thought that a hardware window should work regardless the kind of page-flipping system. Thanks, Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Graphics2D - RFE 6350026 - your votes, please
From SUN: Thank you for reporting this issue. We have determined that this report is a new bug and entered the bug into our internal bug tracking system under Bug Id: 6350026. You can monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6350026. 1. Voting for the bug Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6350026 2. Adding the report to your Bug Watch list. You will receive an email notification when this bug is updated. Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6350026 Cheers! Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] convolveBI - EXCEPTION_ACCESS_VIOLATION
Hi Andrew, the bug is not easily reproducible and that's the reason why I haven't a testcase for the problem. Maybe the following info can be of some help for you: - The image type is always TYPE_INT_ARGB - The image dimensions... varying but not more than 2048x2048 (about 500x100 during the crash) - The image is constructed and used in different threads (hhmmm..). I'l try to reproduce the problem with the latest Mustang. Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Andrew Brygin [EMAIL PROTECTED] To: Michele Puccini [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 31, 2005 3:39 PM Subject: Re: [JAVA2D] convolveBI - EXCEPTION_ACCESS_VIOLATION Hi Michaele, Do you have testcase we can use to reproduce the problem? It will greatly simplify our investigation. (e.g. info about image type, dimensions, whether image constructed and used in the same thread, etc.) Also please check whether this problem is reproducible with latest Mustang builds. Thanks, Andrew Michele Puccini wrote: Hi Java2D team, sometimes I get this pid coming from sun.awt.image.ImagingLib.convolveBI(). It is quite difficult to reproduce, but I hope the dump will help you in drawing the possible causes. Config: JRE 1.5.0_05 P4 3.2Ghz (HT on) 1Gb ram NVidia FX5700 128Mb Cheers, Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] java2d Glyph questions
Thanks all for the hints. while stringWidth() is not for me (I want to get te maximum w,h of the glyphs in a font), g2d.getFontMetrics().xxx() sounds promising. I'll do further checks and let you know. Mik ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it - Original Message - From: Bill Dodson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 21, 2005 8:48 PM Subject: Re: [JAVA2D] java2d Glyph questions I am not the person to give a definitive answer, but have you tried the FontMetrics class? I get the total width and height of a string with the following code: int sw = g2d.getFontMetrics().stringWidth(text); int sh = g2d.getFontMetrics().getHeight(); I notice there is also a getMaxCharBounds in this class. It uses a Graphics context instead of FontRenderContext. Hope this helps. bill === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] SwingSet2 JColorChooserDemo
Hello, I'm facing a strange behavior of the Swingset2 JColorChooser demo. The animated bezier curve flashes around the screen instead of animating smoothly. This happens with jdk 1.5.0_03 , _04 on three different machines: 1) P4 3.2Ghz-HyperThreading- 1Gb ram, Matrox Parhelia, WinXP - jdk1.5.0_03 2) P4 3.2Ghz-HyperThreading- 1Gb ram, Nvidia FX 5200, WinXP - jdk1.5.0_04 3) P4 3.2Ghz-HyperThreading- 1Gb ram, Nvidia FX 5700, WinXP - jdk1.5.0_04 Further tests outlined that the problem is related to P4 Hyper Threading. When the HT is ON than the refresh problem pops up. If HT is OFF then the spline runs smoothly on the screen. I hope someone of the Java2D team can give it a try to see what happens. Cheers, Mik -- === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?)
- Original Message - From: Chris Campbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 2:27 AM Subject: Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?) In 1.5-beta2, which will be out Real Soon Now. Thanks for your reply. Software loops optimizations sound really interesting. Last question: Are you (SUN) going to make an official announcement of the upcoming new hardware accelerated Java2D technology in close time ? Cheers, Mik ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?)
- Original Message -
From: Chris Campbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 1:17 AM
Subject: Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?)
Well, I would like to say you [RE]make my day but I feel this should not
be too correct and at least it's going to be a looping {while(true)}
concept of my last emails. I cannot hide my excitement anyway. I'm sure you
understand..
Looks like the OGL pipeline almost accelerates every aspect of Java2D.
.Is there any suggested board or config in order to use OGL acceleration ?
.Which OpenGL version is required ?
.Can you tell me which Java2D features are not accelerated, apart from
bicubic interpolation ?
.Ah, yes, the last very original question: when ?
Cheers,
Mik
ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI)
Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] bug-id 5008045 (OpenGL for Win ?)
You make my day, Chris! (I'm using this you make my day idiomatic phrase because I'm quite sure it means something like you make my day happier with this positive news. English is not my primary language so correct me, just in case..). Can you anticipate if will we have: - hw accelerated transforms (bitmap, vectors, with translucence support) - hw accelerated transforms (bitmap, vectors, with translucence support) with bilinear, bicubic filtering. - hw accelerated stroke/fill/paint - hw accelerated clipping - hw accelerated shapes, glyphs, text - hw accelerated antialiased shapes, glyphs, text The question is how current applications can take advantage from the new pipeline ? Should we take a particular coding approach for pushing apps performace to the top ? Don't tell me you didn't expect my simple questions Cheers, Mik p.s. [1 April is the Fool's Day even in Italy..] ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] bug-id 5008045 (OpenGL for Win ?)
OGL: add OpenGL-based pipeline for Windows http://developer.java.sun.com/developer/bugParade/bugs/5008045.html Looks like we'll get preliminar opengl acceleration on win in jdk1.5.0b2. Chet, please tell me that's true! Mik of ClassX ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] TransAccel
What we both probably miss is the possibility to write directly to accelerated image data (gfx board memory). Maybe I'm mistaking, but I guess there's something in the current java2d implementation or maybe a combination of hardware/software reasons that prevents the java2d staff to let us do this. Maybe direct gfx memory allocation could solve this problem, but this feature could be a bit out-of-scope for the current Java2D. Mik ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it - Original Message - From: Jonathan Shore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 03, 2004 3:34 AM Subject: Re: [JAVA2D] TransAccel I was pondering the same question. I've noted that setting pixels via the data buffer directly is 10x !!! faster than going through setRGB() on my machine (I have a 2.4Ghz P4 with top of the line ATI graphics card [windows]). I had thought that it was just code overhead in the layers or would the differential between cache/DRAM vs VRAM be that significant? If I am going to be writing pixels across a buffered image on, say, 1 in 5 renders does it ever make since to use setRGB() at 1/10th write perf? Is there a good guide to the performance differences for accelerated and unaccelerated operations? Kind of feeling around in the dark with this stuff, would be good to know more about what is going on underneath to make better rendering decisions ... -- Jonathan Shore Derive Inc -Original Message- From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] On Behalf Of Chet Haase Sent: Friday, April 02, 2004 10:14 AM To: [EMAIL PROTECTED] Subject: Re: [JAVA2D] TransAccel Hi Mik, A simple question about a relatively complicated subject... You have tripped upon the internal rasterStolen variable that we use to detect when someone has accessed the Raster/DataBuffer of a managed image. We can accelerate managed images only when we know exactly what is going on with the main copy of that image. That is, if we can detect when that main copy changes, then we know when to update our accelerated cache of that image. But the API you are using to access the pixels (getDataBuffer()) defeats this approach because we can no longer detect when the main copy has changed. That is, when you have array access into the pixel data, we cannot easily detect when you change values in the array, thus we cannot know when the original copy has changed and our cached version nees to be updated. So we punt. There may be better ways for us to manage this internally in the future, but for now we simply detect the case where someone has gotten direct access to the pixel data and turn off acceleration for that image. The best ways to access the data in a managed image without causing this punt are any methods that render to the image without returning the data buffer. This includes the setPixel methods in Raster and the setRGB methods in BufferedImage; both of these change the data without giving you arbitrary access to the data, so we can detect that the data has changed and update the cached/accelerated image appropriately. Another approach is to render to a different image (perhaps a translucent or transparent one) and then use drawImage() to copy the data in. Finally, you can always use the standard rendering primitives to tweak the data (drawLine(), fillRect, etc.). None of these may be the fastest in the world for setting pixel data, but at least they will allow you to set the data without defeating acceleration. The current state of hw accelerated images is that they work well for static data, but are suboptimal for dynamic data. This is just a result of the kinds of things we needed to accelerated first in our long road toward full-on hw acceleration of everything. The approach you use in your app depends on the performance tradeoff between changing the pixel data in the image versus copying those images to some accelerated surface (e.g., the back buffer). For some applications, it might work out better to have dynamic sprites/images in software because our read/write access to that data is much faster than when those images are stored in VRAM. But if you are not changing those sprites/images too frequently, then you will probably do better by leaving them in VRAM so that they benefit from the hw accelerated copy operations. As always, benchmark if you need to know the Right Answer for your situation. Chet. Michele Puccini wrote: Hello, a simple question: I tried to access the pixels directly through Raster-DataBufferInt but as soon as I call: DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer()); the image becomes non accelerated and there's apparently no way to re-accelerate it. I also
[JAVA2D] TransAccel
Hello, a simple question: I tried to access the pixels directly through Raster-DataBufferInt but as soon as I call: DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer()); the image becomes non accelerated and there's apparently no way to re-accelerate it. I also noticed that setting the raster pixels with: raster.setPixel(x,y,a,r,g,b); works, but I suppose this solution gives very low performance. so the question is: which is the bset way to change the pixels of an accelerated (managed) image on the fly ? Cheers, Mik of ClassX ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Composite
Hello all, is there any opensource Composite implementation for common pixel operations like ADD, SUB ,SOLARIZE, XOR, OR, AND, MULTIPLY, DIVIDE, SCREEN, etc. I gave a look at SVGComposite, but it does not support all these methods. Thanks, Mik p.s. all my best to Vincent (CASTALIA's ready and I would like to send you a copy by snail mail. An address ?). -- ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
