Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  OGL pipeline improvements  (Read 6172 times)
0 Members and 1 Guest are viewing this topic.
Offline campbell

Junior Devvie




Java games rock!


« Posted 2005-03-12 01:30:50 »

The OpenGL-based Java 2D pipeline has been revamped in Mustang-b27 for improved performance and stability.  For more info:
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html

Please download the latest Mustang binary snapshot (build 27, available today) and take it for a spin:
http://www.java.net/download/jdk6/binaries/

Feedback is greatly appreciated.  The more people testing this stuff, the better the chance of enabling the OGL pipeline by default in a future release.  (And in that case, everybody wins, right?)

Thanks,
Chris
Offline Spasi
« Reply #1 - Posted 2005-03-12 09:51:19 »

Awesome release. I hadn't tested the OGL pipeline since 5.0 and I'm impressed at how much improved it is now. On win32, GeFX, 76.10 drivers:

- Everything is looking great, no glitches whatsoever.
- I get ~2-3 times better performance on most demos of Java2Demo.
- All my swing apps are running with no problem.
- I even tested IDEA, everything looks and runs nice, except for this (which you're obviously aware of):

1  
2  
3  
4  
5  
6  
7  
8  
9  
java.lang.InternalError: not implemented yet
      at sun.java2d.opengl.OGLSurfaceData.getRaster(Unknown Source)
      at sun.java2d.loops.GeneralRenderer.doSetRect(Unknown Source)
      at sun.java2d.loops.XorFillSpansANY.FillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.fillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
      at sun.java2d.pipe.PixelToShapeConverter.drawLine(Unknown Source)
      at sun.java2d.pipe.ValidatePipe.drawLine(Unknown Source)
      at sun.java2d.SunGraphics2D.drawLine(Unknown Source)
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #2 - Posted 2005-03-12 10:31:55 »

Campbell, personally I'm for moving to Mustang permamently but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.

I also don't understand why you believe Java defaulting to D3D on Windows is better because I get poor performance under the D3D pipe vs the GL pipe when it comes to transforms and transparent/translucent images.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #3 - Posted 2005-03-12 10:55:09 »

Quote
but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.


No issues here, with any build.

Quote
I also don't understand why you believe Java defaulting to D3D on Windows is better because I get poor performance under the D3D pipe vs the GL pipe when it comes to transforms and transparent/translucent images.


From what I've read, they plan to apply the same techniques used in the OGL pipeline (most importantly, the STR) to the D3D as well.
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #4 - Posted 2005-03-12 12:01:48 »

Please do not beat me, this are just the experiences on my laptop with a Geforce-Go488 (basically a tuned 4MX:

- Gradient Paint is REALLY slow when accerlated (not AA)
- For many other rendering operations performance is about 1/2 of the X11/XRender pipeline, only in some special cases I get 2x-5x performance improvements.
- Performance sometimes choppes, it goes fast, then slow, then fast. This is especially the case when running the circle-demo of java2ddemo.

I think most are driver-issues, however....

Thanks anyway for the hard work, lg Clemens
Offline javazoid

Junior Devvie




Where's Flender?


« Reply #5 - Posted 2005-03-14 11:36:02 »

I'm getting some benefits from the new implementation (and yes, I'm using a similar single-thread design in my LWJGL based api).

No more crashes at system.exit with my NVidia drivers 66.93.

I'm facing some little java2d problems, maybe related to the swing glasspane: the control handles of Castalia objects do not show at all.

Does the new implementation support translucent volatile image acceleration ?

Cheers,

Mik

Offline SDV

Senior Newbie





« Reply #6 - Posted 2005-03-14 12:40:02 »

Quote
Does the new implementation support translucent volatile image acceleration ?

well yes.... try java -Dsun.java2d.translaccel=true
but it seems that it wont work with -Dsun.java2d.opengl=True
also i know only how translucent v's work on my pc.... and its like opque ones only that they run slower Wink no transparecy at all :/
Offline campbell

Junior Devvie




Java games rock!


« Reply #7 - Posted 2005-03-14 13:22:32 »

Quote

- I even tested IDEA, everything looks and runs nice, except for this (which you're obviously aware of):

1  
2  
java.lang.InternalError: not implemented yet
      at sun.java2d.opengl.OGLSurfaceData.getRaster(Unknown Source)


I'm aware of this limitation, but I can't tell from the stack trace what is causing the problem.  Could you email me the full stack trace, or perhaps more detail on how to reproduce it, and then I'll look into it...

Thanks,
Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #8 - Posted 2005-03-14 13:29:29 »

Quote
Campbell, personally I'm for moving to Mustang permamently but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.


Well, the Mustang snapshots should be beta quality, but they're not intended for production use.  That said, there's nothing in there that should break existing apps.  It would be great if you did use the weekly Mustang snapshots, and then report problems if/when you see them.

Quote

I also don't understand why you believe Java defaulting to D3D on Windows is better because I get poor performance under the D3D pipe vs the GL pipe when it comes to transforms and transparent/translucent images.


That's because the D3D pipeline rearchitecture hasn't been integrated yet into Mustang.  Those changes will produce better performance on Windows than even the OGL pipeline for things like transforms and compositing.  And regardless of the performance numbers, the DirectX-based APIs are better supported in Windows drivers and by Microsoft going forward than OGL ever will be.

Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #9 - Posted 2005-03-14 13:36:31 »

Quote
Please do not beat me, this are just the experiences on my laptop with a Geforce-Go488 (basically a tuned 4MX:

- Gradient Paint is REALLY slow when accerlated (not AA)
- For many other rendering operations performance is about 1/2 of the X11/XRender pipeline, only in some special cases I get 2x-5x performance improvements.
- Performance sometimes choppes, it goes fast, then slow, then fast. This is especially the case when running the circle-demo of java2ddemo.

I think most are driver-issues, however....

Thanks anyway for the hard work, lg Clemens


When you report issues like this, please mention the OS and driver version being tested.

I've seen the slow GradientPaint issue on very old GeForce (2) boards, so it might be a hardware limitation.  I'll have to check with Nvidia about that.

We don't use XRender at all (currently) in our X11 pipeline, so it's incorrect to say otherwise.  Anyway, please provide more detail about which operations are slower than with the X11 pipeline (e.g. which Java2Demo sub-panels, which hints enabled).

Same details would be needed about your "Circles" demo report.  Was AA on or off?  Etc, etc.

Thanks,
Chris
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline campbell

Junior Devvie




Java games rock!


« Reply #10 - Posted 2005-03-14 13:41:23 »

Quote
I'm getting some benefits from the new implementation (and yes, I'm using a similar single-thread design in my LWJGL based api).

No more crashes at system.exit with my NVidia drivers 66.93.

I'm facing some little java2d problems, maybe related to the swing glasspane: the control handles of Castalia objects do not show at all.


Hi Mik,

Thanks for trying it out.  Could you provide a testcase for the problem you describe?  Or at least a description of how the control handles are rendered?

Quote

Does the new implementation support translucent volatile image acceleration ?


No, still no translucent VolatileImage acceleration.  There's still an RFE open for this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002129

Thanks,
Chris
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #11 - Posted 2005-03-14 17:53:46 »

Quote

When you report issues like this, please mention the OS and driver version being tested.

I've seen the slow GradientPaint issue on very old GeForce (2) boards, so it might be a hardware limitation.  I'll have to check with Nvidia about that.


To be honest, I always thought SUN isn't really interrested in getting suer feedback.

Quote
.
We don't use XRender at all (currently) in our X11 pipeline, so it's incorrect to say otherwise.

Well, great! So there's always room left for improvements *g*

Here are some results from mustang-b27 on my laptop:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
All animations were run with the default window-size in maximized mode (so this animation is the only one), with the default settings.

worst:
BezirAnim      X11:100fps    X11AA:90fps   OGL:18fps   OGLAA:130fps
Clipping.Areas X11:90fps     X11AA:84fps   OGL:9.6fps  OGLAA:~150fps
GradAnim       X11:135fps    X11AA:77fps   OGL:3.5fps  OGLAA:60fps

not so good:
LineAnim       X11:750fps    X11AA:74fps   OGL:350fps  OGLAA:133fps

great:
TextureAnim    X11:138fps    X11AA:86fps   OGL:650fps  OGLAA:63fps



Some driver-infos:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce4 488 Go/AGP/SSE2
OpenGL version string: 1.5.3 NVIDIA 71.67 (had similar experiences with the latest 6xxx)

AGP:
Status:          Enabled
Driver:          AGPGART
AGP Rate:        8x
Fast Writes:     Disabled
SBA:             Enabled

Linux-Kernel:     2.6.9

xorg 6.8.1 with RenderAccl activated.


Hope it helps a bit - Good luck!
Offline campbell

Junior Devvie




Java games rock!


« Reply #12 - Posted 2005-03-14 20:01:32 »

Quote


To be honest, I always thought SUN isn't really interrested in getting suer feedback.


I'm not sure who/what gave you that impression, but we do take user feedback seriously... Especially in this case, the more data we get, the greater the possibility of enabling the OGL pipeline.

Quote

Here are some results from mustang-b27 on my laptop:
[snip]


Thanks for the details.  I believe you meant "ClipAnim" instead of "Clipping.Areas", which isn't animated, correct?

I'm able to reproduce your findings on a GeForce MX4000 board, as well as an older GF2 MX400.  I believe the boards are based on the same chip, as is your GF 488 Go.

The poor performance in the three "worst" cases you mention are due to the lack of acceleration of GradientPaint on these boards, as I suspected.  I will file a bug report with Nvidia.  If it turns out to be a hardware limitation, then we might have to find some way to disable our gradient acceleration mechanism conditionally on this family of boards (yuck).

In the "not so good" case, the slowdown may be attributed to the small drawPoly() calls, which we may be able to optimize.  I'll look into it.

I've also thought of ways to improve gradient performance when AA is enabled, so the "OGLAA" score may improve in your "great" case.

Thanks for the feedback.  I'll post again if I get some information from Nvidia about these issues.

Chris
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #13 - Posted 2005-03-15 03:57:01 »

Quote

The poor performance in the three "worst" cases you mention are due to the lack of acceleration of GradientPaint on these boards, as I suspected.  I will file a bug report with Nvidia.  If it turns out to be a hardware limitation, then we might have to find some way to disable our gradient acceleration mechanism conditionally on this family of boards (yuck).

Yes, sorry for this mistake  Embarrassed
Quote

The poor performance in the three "worst" cases you mention are due to the lack of acceleration of GradientPaint on these boards, as I suspected.  I will file a bug report with Nvidia.  If it turns out to be a hardware limitation, then we might have to find some way to disable our gradient acceleration mechanism conditionally on this family of boards (yuck).

Well, I think this is the best idea! Enable optimizations if they are possible, but do not try to support all those low-end cards and make the fast ones slower.


Another other not_so_good_cases:
1  
2  
3  
Curves.Arcs      X11:1000fps    X11AA:85fps   OGL:300fps   OGLAA:163fps
Clipping.Intersection  X11:500-1000fps  X11AA:75fps   OGL:300fps  OGLAA:~100fps
BezierScroller (only text): X11:1300fps  X11AA:92fps  OGL:400fps OGLAA:300fps

You see, most tests runs slower using the OGL pipeline on my hardware :-(

Btw, the choppy performance I reported to the ogl-pipeline occurs just with the X11-pipeline, seems I messed something.
It occurs e.g. with BezierScroller(text), after startup I get 1300fps, after minimazing the window a couple of times the performance falls to 100fps and stays there. No idea whats wrong :-(

lg Clemens
Offline javazoid

Junior Devvie




Where's Flender?


« Reply #14 - Posted 2005-03-22 05:44:29 »

Quote
Hi Mik,

Thanks for trying it out.  Could you provide a testcase for the problem you describe?  Or at least a description of how the control handles are rendered?


With the new b28 everything works fine with or without the OGL pipeline. By this time I upgraded my NVidia drivers to 71.84 and maybe this fixed the problem.

Cheers,

Mik

Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #15 - Posted 2005-03-25 14:06:00 »

Btw. Netbeans no longer crashes on OGL mode when opening the main-window. With 1.5 I got an "illegal async reply" message and the whole thing died :-(

I also noticed better performance for "normal" rendering operations like lines, rects and text - maybe the Java2D-Demo isn't well suited for testing those low-level calls since it uses only more complex higher-level features.

Great to see progress on this task!

lg Clemens
Offline campbell

Junior Devvie




Java games rock!


« Reply #16 - Posted 2005-03-25 14:43:02 »

Quote
- I even tested IDEA, everything looks and runs nice, except for this (which you're obviously aware of):

1  
2  
3  
4  
5  
6  
7  
8  
9  
java.lang.InternalError: not implemented yet
      at sun.java2d.opengl.OGLSurfaceData.getRaster(Unknown Source)
      at sun.java2d.loops.GeneralRenderer.doSetRect(Unknown Source)
      at sun.java2d.loops.XorFillSpansANY.FillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.fillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
      at sun.java2d.pipe.PixelToShapeConverter.drawLine(Unknown Source)
      at sun.java2d.pipe.ValidatePipe.drawLine(Unknown Source)
      at sun.java2d.SunGraphics2D.drawLine(Unknown Source)


This bug has been resolved as part of the fix for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106309

This fix (along with a bunch of others) will be available in an upcoming Mustang snapshot (probably b32 or so).

Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #17 - Posted 2005-03-25 14:56:13 »

Thanks, everyone, for your feedback.  There are still a few performance tweaks and minor bug fixes that we're making in our Java 2D code; these will be available in an upcoming build.  As for the driver-specific issues I discussed earlier, I've been filing bugs against the vendors.  Here is a partial list of the ones I've filed in the past few weeks:

Nvidia
- glCopyPixels() is very slow for pbuffers (Windows only?)
- Java 2D shape clip problems on GF2-based boards (Windows only)
- Lines are missing endpoints on GF2-based boards
- Java 2D GradientPaint is very slow on GF2-based boards

ATI
- Java/Swing apps crash upon exit
- Gradients rendered incorrectly in Java 2D apps
- Images rendered with Java 2D sometimes have red/blue components swapped

Please continue to file bugs and report any issues you're seeing.  I'll post updates if I get any new info on these driver issues.

Thanks,
Chris
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #18 - Posted 2005-03-26 07:37:43 »

I reported another bug I came across about one month ago, but did not get any repsonse till now.
The ID is: 409145 - but its not visible till now.

The bug-report was that the size of volatile/managed images created via Component.createImage() is limited.
However I've found out some other facts which seem to show that this is an Java2D and not a driver bug:

* The size of the image is limited to the highest-level-heavyweight component. If you have a component-hirarchy of JFrame(500, 500)->(AWT)Panel(300, 300)->(AWT)Panel(100, 100) and you create the image on the highest-level panel (100, 100) then the size of the backbuffer-image will be limited to 100, 100.
If you use JPanels instead of Panels your image is limited to (500, 500), because that is the size of the highest-level heavyweight component (JFrame in this case).
This happens for both, Volatile and Managed images.

* If I increase the size of the generated image to something bigger than 4096, everything works quiet fine. (I then then accerlation is turned off).

* This bug happend in 1.5 and the Mustang-builds too.

Hope this helps, lg Clemens

I also have an ugly test-case:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
import java.awt.*;
import javax.swing.*;

/**
 * (c) Clemens Eisserer
 */

public class OGLTest extends Panel implements Runnable
{
    Image contentImage;
    public static final int contentWith = 200;
    public static final int contentHeight = 4096;
    
    int currScrollPos = 0;
    
    public OGLTest()
    {
        Frame f = new Frame();
        f.setSize(800, 800);
        f.setVisible(true);
        
        f.setLayout(null);
        this.setLocation(20, 20);
        this.setSize(500, 500);
        f.add(this);
        
        contentImage = createImage(contentWith, contentHeight);
        drawContent();
        
        Thread t = new Thread(this);
        t.start();
    }
    
    
    public void paint(Graphics g)
    {
        g.setColor(Color.white);
        g.fillRect(0, 0, 500, 500);
        
        g.setColor(Color.black);
        g.drawString("That is the clipping test", 100, 100);
        g.setClip(0, 150, 500, 300);
        g.drawImage(contentImage, 0, currScrollPos, this);
    }
    
    public void run()
    {
    
          while(true)
          {
              currScrollPos--;
              if(currScrollPos < -(contentHeight-300)) currScrollPos = 0;
              Thread.yield();
              this.repaint();
          }

    }
    
    private void drawContent()
    {
        Graphics contentG = contentImage.getGraphics();
        GradientPaint paint = new GradientPaint(0f, 0f, Color.red, (float) contentWith, (float) contentHeight, Color.yellow, true);
        ((Graphics2D) contentG).setPaint(paint);
        contentG.fillRect(0, 0, contentWith, contentHeight);
        contentG.setColor(Color.black);
        ((Graphics2D) contentG).setPaint(null);
        contentG.drawRect(1, 1, contentWith-2, contentHeight-2);
        for(int i=0; i < contentHeight; i+= 20)
        {
            contentG.drawString(String.valueOf(i), 20, i);
        }
    }
    
    public static void main(String[] args)
    {
      new OGLTest();
    }
}
Offline Spasi
« Reply #19 - Posted 2005-03-26 11:21:44 »

Quote
Thanks, everyone, for your feedback.  There are still a few performance tweaks and minor bug fixes that we're making in our Java 2D code; these will be available in an upcoming build.


Are there any plans for Mustang to implement a path for render-to-texture operations with EXT_framebuffer_object? By the time Mustang development finishes, I would expect implementations of this extension to be widely available. It would improve both performance and (video) memory consumption (especially on non-Windows platforms).
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #20 - Posted 2005-03-28 13:48:27 »

Quote

That's because the D3D pipeline rearchitecture hasn't been integrated yet into Mustang.  Those changes will produce better performance on Windows than even the OGL pipeline for things like transforms and compositing.  And regardless of the performance numbers, the DirectX-based APIs are better supported in Windows drivers and by Microsoft going forward than OGL ever will be.

Chris


Chris,

could you list or explain in details what are the anticipated improvements with the rearchitectured D3D pipeline please? You talked about transforms. Which transform operations? What are the other improvements? Also do you know if these improvements risk to be integrated in release like 1.5.1 for example? I think I really need these performance improvements if I want to create fast special effects in my game using Java2D. I'd really like to continue with Java2D and not beign forced to switch to that ugly OpenGL programming model via LWJGL because of performance issues.

Thanks!

Offline campbell

Junior Devvie




Java games rock!


« Reply #21 - Posted 2005-03-28 15:12:54 »

Quote
I reported another bug I came across about one month ago, but did not get any repsonse till now.
The ID is: 409145 - but its not visible till now.

The bug-report was that the size of volatile/managed images created via Component.createImage() is limited.
However I've found out some other facts which seem to show that this is an Java2D and not a driver bug:


Sorry that your bug report was waiting in our submission queue for a while.  I just kicked it into our bug database, tracked under 6246760.  I'll look into it more closely this week but first a couple quick notes...

In an upcoming Mustang build (b32 maybe?) you will no longer run into this problem because createImage() will now always be returning a "normal" managed image for the OGL pipeline, instead of a wacky pbuffer-based variant.  See 6240664 for more details.

Even so, VolatileImages will continue to be backed by pbuffers, so this problem may still be present.  I'll have to dig deeper to see what's going on here.

Thanks again for reporting the issue.
Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #22 - Posted 2005-03-28 15:19:16 »

Quote


Are there any plans for Mustang to implement a path for render-to-texture operations with EXT_framebuffer_object? By the time Mustang development finishes, I would expect implementations of this extension to be widely available. It would improve both performance and (video) memory consumption (especially on non-Windows platforms).


Hi Spasi,

We've been tracking this extension for quite some time, and I agree that it might be useful for us (probably in the Dolphin (7.0) timeframe, rather than for Mustang).  It may only be implemented for newer hardware, in which case we'll still have to maintain our existing pbuffer/render-to-texture implementations.  When/If this extension is more widely supported, it would be great if we could replace our existing platform-specific code entirely, as this extension would make it easy to manage offscreen surfaces in shared code.

Thanks,
Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #23 - Posted 2005-03-28 15:25:22 »

Quote


Chris,

could you list or explain in details what are the anticipated improvements with the rearchitectured D3D pipeline please? You talked about transforms. Which transform operations? What are the other improvements? Also do you know if these improvements risk to be integrated in release like 1.5.1 for example? I think I really need these performance improvements if I want to create fast special effects in my game using Java2D. I'd really like to continue with Java2D and not beign forced to switch to that ugly OpenGL programming model via LWJGL because of performance issues.

Thanks!


Hi there,

Dmitri will post more details about the D3D pipeline improvements sometime in the next couple weeks (we're hoping).  We'll start a new thread for discussing this work, rather than take this OGL thread off-topic.  Sorry to be vague, but rest assured that the improvements will be available soon in an upcoming Mustang build.

Thanks,
Chris
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #24 - Posted 2005-04-03 12:22:03 »

Hi again!

I've just reported another bug, RoundRect renderes exactly 1px too high when using the OGL pipeline.
The id is: 421444 - but since I reported it just today I do not expect to get answer soon :-(

Regarding the createImage will return BufferedImage, wouldn't it be possible to release the memory hold by the BufferedIage itself, if no one draws on it for a long time (and its blitted a lot?).
If something should be drawn again to such an optimized image, java cold detect this, render from the textture->bufferedImage again and could set a flag to never again try to save the system-memory.
Because I think textures are not allowed to loose their content, aren't they?


lg Clemens
Offline campbell

Junior Devvie




Java games rock!


« Reply #25 - Posted 2005-04-04 21:28:08 »

Quote
Hi again!

I've just reported another bug, RoundRect renderes exactly 1px too high when using the OGL pipeline.
The id is: 421444 - but since I reported it just today I do not expect to get answer soon :-(


Thanks for your report.  I evaluated it as a duplicate of a couple other existing bugs, which we hope to have fixed in Mustang.

Quote

Regarding the createImage will return BufferedImage, wouldn't it be possible to release the memory hold by the BufferedIage itself, if no one draws on it for a long time (and its blitted a lot?).
If something should be drawn again to such an optimized image, java cold detect this, render from the textture->bufferedImage again and could set a flag to never again try to save the system-memory.
Because I think textures are not allowed to loose their content, aren't they?


This is something we've considered... OGL textures are not supposed to lose their content, but I'm not so sure this is guaranteed, especially after display changes.  Also, it's not easy to read back from an OGL texture object into system memory (it can be done, but you need some available offscreen VRAM to do this, which isn't always guaranteed).  For these reasons and a few others, we're not likely to implement anything like this soon.  Are you simply concerned with memory consumption of managed images?

Thanks,
Chris
Offline princec

« JGO Spiffy Duke »


Medals: 437
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2005-04-05 07:19:45 »

The way OpenGL works is that when you call glTexImage2D it takes a copy of the image you point to and places it in system RAM, and manages it forever after for you, putting it into and out of VRAM as necessary. However I have encountered some really old, really shitty drivers from Matrox that failed to take a copy and actually kept ahold of the pointer. But my advice is simply to ignore drivers that do this as it is completely incorrect behaviour.

Likewise glCopyTexImage2D doesn't need VRAM to copy into, it copies the data back out into system RAM for you to do with as you please.

So basically if you were to back a BufferedImage with a GL texture you may as well free the heap RAM (which is what I do in my games)

Cas Smiley


Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #27 - Posted 2005-04-05 14:54:20 »

I was just concerned since it seems not to be possible to hold blit-only images as icons, there's always the bufferediameg data arround.

I do not only think about games but also about applications using many icons and so on.

lg Clemens
Offline campbell

Junior Devvie




Java games rock!


« Reply #28 - Posted 2005-04-06 16:58:57 »

Quote

Nvidia
- Java 2D GradientPaint is very slow on GF2-based boards

ATI
- Gradients rendered incorrectly in Java 2D apps


Good news on these issues reported earlier.  We found a slight tweak that makes GradientPaint performance on GF2-series boards consistent with other boards.  So instead of ~3 fps for demos involving GP (with AA disabled), you should now see ~400 fps.  (The GF2 series includes chips like GF Go 440, GF MX 4000, etc, so Clemens, you should see a big improvement here.)  Also, as icing on the cake, this change also makes gradients render properly on ATI Radeon series boards (instead of just rendering black).

The bugid for this change is 6251468 and should be visible on the JDC tomorrow.  This fix along with a bunch of others will be available soon in Mustang-b33.

Thanks,
Chris
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #29 - Posted 2005-04-08 05:57:30 »

wow - great! Thats of course the best solution, better than doing it in software ;-)

Maybe this will also speed up the ozean theme a bit - great.

Thanks, lg Clemens
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (55 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (91 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (83 views)
2014-12-05 12:39:02

SHC (92 views)
2014-12-03 16:27:13

CopyableCougar4 (101 views)
2014-11-29 21:32:03

toopeicgaming1999 (160 views)
2014-11-26 15:22:04

toopeicgaming1999 (163 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!