Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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  
  can a translucent image be quicker to draw than a bitmask one?  (Read 6072 times)
0 Members and 1 Guest are viewing this topic.
Offline No_Germs

Junior Member





« Posted 2005-09-11 01:12:15 »

i've noticed that if i load my sprites as translucent images the rendering is faster than when loading them as bitmask images...
how is this possible?
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #1 - Posted 2005-09-11 03:31:06 »

Only situation I can think of that  could cause that (excluding driver peculiarities) would be :-

1) If you were using Java 1.5
2) and you didn't have the OGL pipeline enabled
3) and you were using createCompatibleVolatileImage(w,h,transparency)
4) and you were drawing the image onto an unaccelerated surface.


In that situation, the volatile Image with translucency would be created in main memory (because, by my understanding translucent volatile images arn't accelerated by default in 1.5)
Where as the bitmask volatile image would be created in vram.

Obviously with the target image in main memory not vram,
a main -> main blit would be quicker than a vram -> main blit. (due to vram readback  being painfully slow )

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline No_Germs

Junior Member





« Reply #2 - Posted 2005-09-11 07:08:31 »

1. I don't qualify for 3). it's a BufferedImage.
2. i think you're wrong... the createCompatible... means it creates the image most suited for the enviroment. if the enviroment uses an accelerated buffer (in vram) the image would (try) to be in vram too. if the back buffer is not in vram i think the image wouldn't be in vram neither.

i think the images can't be cached as they are bigger than 256X256...
anyway, i'm getting really frustrated with all this unexcpected behaviour...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #3 - Posted 2005-09-11 08:36:57 »

createCompatibleImage(w,h,transparency) _attempts_ create an image most suitable
for rendering to the device. Buf if you're trying to create a translucent compatible image,
there may be no way to have anything more suitable than just plain IntArgb BufferedImage.

As translucent images weren't accelerated in 5.0, rendering them to a volatileImage would
cause the latter to be punted to system memory to avoid doing readbacks from vram.

Some data on your environment (video board, os) wouldn't hurt, btw.

Also, -Dsun.java2d.trace=count is your friend. Run with this option with your
images being loaded as translucent and as bitmask images. From that it'd be easier
to see what loops are being used.

Dmitri
Java2D Team
Offline No_Germs

Junior Member





« Reply #4 - Posted 2005-09-11 12:14:32 »

here's some code:
class Mountain
      public Mountain()
      {
///      some other coed here...
      GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
      GraphicsDevice gs = ge.getDefaultScreenDevice();
       GraphicsConfiguration gc = gs.getDefaultConfiguration();

            //this works runs faster with Transparency.TRANSLUCENT than with Transparency.BITMASK
       SetImage = gc.createCompatibleImage(Width,Height,Transparency.TRANSLUCENT);

      Graphics g=SetImage.getGraphics();
      Graphics2D G2=(Graphics2D)g;
      G2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
              RenderingHints.VALUE_ANTIALIAS_ON);
      G2.setRenderingHint(RenderingHints.KEY_RENDERING,RenderingHints.VALUE_RENDER_QUALITY );
      G2.setPaint(texture);
      g.fillPolygon(XPoints,YPoints,NumOfPoints);//Xpoints is an array of ints
      g.setColor(new Color(0,0,0));
      g.drawPolyline(XPoints,YPoints,NumOfPoints);
      }
      //and this is  the rendering function:
      public void draw(Graphics g)
      {
            g.drawImage(SetImage,DrawX,0,null);
      }     
}
//inside main....
while(true)
{
                g=strategy.getDrawGraphics();
      Graphics2D G2=(Graphics2D)g;

      //clear the screen
                g.setColor(new Color(100,200,255));
      g.fillRect(0,0,theScreen.GetWidth(),theScreen.GetHeight());
      
                //this transforms the coordinate system from( X left to right ,Y up to down) to( X left to right, Y down to up)
      G2.setTransform(StartAT);
                //theMountains is an array of Mountain objects
                for(int i=0;i<theMountains.length;i++)
                {
                        theMountains.draw(g);
                }
            g.dispose();
      strategy.show();
}
you see something that i'm doing wrong?
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #5 - Posted 2005-09-11 13:15:14 »

What does the creation of your BufferStrategy look like?

My guess is that this line :-
Quote
G2.setTransform(StartAT);

Is preventing the accelerated pipeline from being used.

Therefor, both BITMASK and TRANSLUCENT images are being drawn through the software blit loops.

Now, because TRANSLUCENT blits require readback from the BufferStrategy's VolatileImage back buffer,
the rendering pipeline is being sensible and shunting the backbuffer out of vram permanently.
Giving you lots of main memory -> main memory blits, followed by just a single main memory ->vram blit at the end.
This would be ok if you have fast system memory.

Whereas blitting a BITMASK image onto the Volatile backbuffer doesn't require pixel readback,
so the backbuffer is left in vram - resulting in alot of main memory -> vram blits.
If your graphics card isn't too speedy, or the AGP bus isn't fast - this will cause a bottleneck.

How much of a speed difference between BITMASK and TRANSLUCENT are we talking about?

Disclaimer

All that is a guess from the limited info available =D

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #6 - Posted 2005-09-12 04:23:08 »

Looks like Abuse got it all right.

In 5.0 and earlier the transformed blits weren't accelerated (unless
the transform is just a translation).

Dmitri
Java2D Team
Offline No_Germs

Junior Member





« Reply #7 - Posted 2005-09-19 21:58:02 »

ok, so how can i over come this problem (besides by switching to mustang)?
and what's the use of using the opengl pipeline if it prevents me from applying transfroms?
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #8 - Posted 2005-09-19 22:13:41 »

ok, so how can i over come this problem (besides by switching to mustang)?
and what's the use of using the opengl pipeline if it prevents me from applying transforms?

If the opengl pipeline is functioning correctly, Transforms *will* be accelerated.
(without the opengl pipeline, transforms will *never* be accelerated in 1.5)

My understanding is that 1.6's d3d pipeline offers equivalent accelerated functionality without relying on opengl. (though I have yet to download and try 1.6)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline No_Germs

Junior Member





« Reply #9 - Posted 2005-09-19 23:56:12 »

In 5.0 and earlier the transformed blits weren't accelerated (unless
the transform is just a translation).
So this applies only to D3D, and OpenGl is Accelerated?
than why can't i use Opengl? i'm not getting accelerated results while enabling the opengl pipeline either...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #10 - Posted 2005-09-20 00:53:03 »

What graphics card do you have? Many cards/drivers suck, wich may be why Java2D refuse to enable the pipeline.

Offline No_Germs

Junior Member





« Reply #11 - Posted 2005-09-22 14:49:21 »

NVIDIA GeForce2 MX/MX 400
Installed Drivers   nv4 (5.01.2001.1240)

Offline No_Germs

Junior Member





« Reply #12 - Posted 2005-09-25 19:15:49 »

hello?
is this hardware can cause such problems or not... don't leave me hangin'...  Wink
Offline campbell

Junior Member




Java games rock!


« Reply #13 - Posted 2005-09-26 05:41:01 »

hello?
is this hardware can cause such problems or not... don't leave me hangin'...  Wink

Those drivers look really old.  Try installing the latest from nvidia.com... I test the OGL pipeline on GF 2 MX 400 all the time without any issues.

Chris
Offline No_Germs

Junior Member





« Reply #14 - Posted 2005-09-27 11:37:45 »

well, i've installed the latest driver from nvidia... it didn't help. any other ideas?
Offline campbell

Junior Member




Java games rock!


« Reply #15 - Posted 2005-09-27 18:06:24 »

well, i've installed the latest driver from nvidia... it didn't help. any other ideas?

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?  If so, what do you see printed to the console?

Chris
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2005-09-27 18:11:14 »

Quote
Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?

No way, are you serious? Uppercase T for verbose mode? Smiley

Kev

Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #17 - Posted 2005-09-27 19:09:35 »

Quote
Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?

No way, are you serious? Uppercase T for verbose mode? Smiley

Kev

Good isn't it Smiley

Just think of all the hidden options you could have!

Almost as good as a png chunk name Tongue

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline campbell

Junior Member




Java games rock!


« Reply #18 - Posted 2005-09-27 21:34:26 »

Quote
Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?

No way, are you serious? Uppercase T for verbose mode? Smiley

Kev

Good isn't it Smiley

Just think of all the hidden options you could have!

Almost as good as a png chunk name Tongue

Yeah, yeah, okay, mea culpa.  I can't believe how much flack we've caught for this one.  I remember reading a blog where some developer was fuming over the whole 't'/'T' thing.  I guess he really must've run out of things to complain about if something like this could keep him up at night Smiley

Chris
Offline No_Germs

Junior Member





« Reply #19 - Posted 2005-09-28 11:27:14 »

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?  If so, what do you see printed to the console?

Chris

well, i've run it with -Dsun.java2d.opengl=True, and it outputed to the console: "OpenGL pipeline enabled for default config on screen 0". that's it...
Offline campbell

Junior Member




Java games rock!


« Reply #20 - Posted 2005-09-28 18:37:05 »

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?  If so, what do you see printed to the console?

Chris

well, i've run it with -Dsun.java2d.opengl=True, and it outputed to the console: "OpenGL pipeline enabled for default config on screen 0". that's it...

Okay, that's a start.  As Dmitri said above, -Dsun.java2d.trace=count is your friend.  That will tell you what is being accelerated by the OGL pipeline, and what is not.  So try again with both the opengl and trace flags, and post the output here.

Chris
Offline No_Germs

Junior Member





« Reply #21 - Posted 2005-09-29 16:06:53 »

Okay, that's a start. As Dmitri said above, -Dsun.java2d.trace=count is your friend. That will tell you what is being accelerated by the OGL pipeline, and what is not. So try again with both the opengl and trace flags, and post the output here.
here it is:

62 calls to OGLDrawGlyphs
468 calls to sun.java2d.opengl.OGLTextureToSurfaceTransform::TransformBlit("OpenGL Texture", AnyAlpha, "OpenGL Surface")
41 calls to OGLDrawRect
36 calls to sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface (render-to-texture)", AnyAlpha, "OpenGL Surface")
6 calls to sun.java2d.opengl.OGLSwToTextureBlit::Blit(IntArgbPre, SrcNoEa, "OpenGL Texture")
38 calls to OGLDrawPoly
82 calls to OGLDrawLine
57 calls to sun.java2d.loops.DrawPolygons::DrawPolygons(OpaqueColor, SrcNoEa, AnyInt)
38291 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbBm, SrcOverNoEa, "OpenGL Surface")
37 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntRgb, SrcNoEa, IntArgbBm)
37 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgb)
37 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(IntRgb, SrcNoEa, IntArgbBm)
2866 calls to OGLFillSpans
39351 calls to sun.java2d.loops.Blit::Blit(IntArgb, SrcNoEa, IntArgbPre)
39363 calls to sun.java2d.opengl.OGLMaskBlit::MaskBlit(IntArgb, SrcOver, "OpenGL Surface")
2 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
37 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbBm)
449 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre)
39602 calls to sun.java2d.opengl.OGLDelegateBlit::Blit(IntArgb, AnyAlpha, "OpenGL Surface")
40731 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre)
39614 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(IntArgbBm, SrcOverNoEa, "OpenGL Surface")
630 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre)
39623 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcNoEa, IntArgb)
188 calls to OGLFillRect
6 calls to sun.java2d.opengl.OGLSwToSurfaceTransform::TransformBlit(IntArgbPre, AnyAlpha, "OpenGL Surface")
282636 total calls to 25 different primitives

what's the conclusion?

Offline campbell

Junior Member




Java games rock!


« Reply #22 - Posted 2005-09-29 18:45:28 »

Okay, that's a start. As Dmitri said above, -Dsun.java2d.trace=count is your friend. That will tell you what is being accelerated by the OGL pipeline, and what is not. So try again with both the opengl and trace flags, and post the output here.
what's the conclusion?

Well, it's still a bit hard to tell since you only show us a snippet of your source code.  But anyway, how many images are there in your "mountains" array?  Are there any other BufferedImages being used in your app?  And how large are they?

You can see from the trace output above that 6 images are being properly cached in texture memory.  But there are many other software blit calls (all those OGLMaskBlits) which leads me to suspect that your other images are not being cached for some reason (maybe because you're grabbing the Raster/DataBuffer using getRaster() and getData()?)... You can use -Dsun.java2d.trace=log to see where these software blit calls are coming from in your application and it will give you an idea of which images are problematic.

Chris
Offline No_Germs

Junior Member





« Reply #23 - Posted 2005-09-29 19:27:59 »

Finally, a breakthrough!
i don't know how i haven't noticed it before, but the drawing only takes long for only two pictures(though smaller ones are not cached either)- the extremely large ones, at the size of about 1066X266 (backgound)  and the other at 65X1100. is this too big for caching. i'm also not drawing the image by using drawImage but instead i create a texturepaint object in order to wrap the image all over the screen. could this be a problem too?
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #24 - Posted 2005-09-29 21:57:34 »

Finally, a breakthrough!
i don't know how i haven't noticed it before, but the drawing only takes long for only two pictures(though smaller ones are not cached either)- the extremely large ones, at the size of about 1066X266 (backgound)  and the other at 65X1100. is this too big for caching. i'm also not drawing the image by using drawImage but instead i create a texturepaint object in order to wrap the image all over the screen. could this be a problem too?

yup

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline tom
« Reply #25 - Posted 2005-09-29 22:24:53 »

That is some extremely bad sizes for images. It's possible that they have to be stored in pow2 textures in wich case you'll really be using a 2048x512 and 128x2048 backgrounds. Max 512x512 would be safe in opengl and 256x256 would be the optimal for the default pipeline. I think Undecided

Offline No_Germs

Junior Member





« Reply #26 - Posted 2005-09-30 02:23:04 »

Finally, a breakthrough!
i don't know how i haven't noticed it before, but the drawing only takes long for only two pictures(though smaller ones are not cached either)- the extremely large ones, at the size of about 1066X266 (backgound)  and the other at 65X1100. is this too big for caching. i'm also not drawing the image by using drawImage but instead i create a texturepaint object in order to wrap the image all over the screen. could this be a problem too?
yup
are you refering to  the first question (about image sizes), or to the second one (about using texturepaint)?

That is some extremely bad sizes for images. It's possible that they have to be stored in pow2 textures in wich case you'll really be using a 2048x512 and 128x2048 backgrounds. Max 512x512 would be safe in opengl and 256x256 would be the optimal for the default pipeline. I think Undecided
so what do i do? chop down every large image into 10 small images?
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #27 - Posted 2005-09-30 11:53:39 »

That is some extremely bad sizes for images. It's possible that they have to be stored in pow2 textures in wich case you'll really be using a 2048x512 and 128x2048 backgrounds. Max 512x512 would be safe in opengl and 256x256 would be the optimal for the default pipeline. I think Undecided
so what do i do? chop down every large image into 10 small images?
Quote

Well each image  (this only applies to todays OpenGL implementations, there are already boards supporting "normal" sizes too) is cache in an OpenGL Texture which has to be x^2 size. so either 64, 128, 256, 512, 1024, 2048 ... and boom since this is the texture-size limit of ATI cards ;-)
So if you could resize your two background-images to 1024x256 and 64x1024 you would save for those two images 75% of texture memory.

Which card are you using? How much memory does it have?

Regarding to the texture-paint problem I don't know - however it should'nt be too hard to try yourself ;-)

lg Clemens
Offline No_Germs

Junior Member





« Reply #28 - Posted 2005-09-30 12:10:03 »

Well each image  (this only applies to todays OpenGL implementations, there are already boards supporting "normal" sizes too) is cache in an OpenGL Texture which has to be x^2 size. so either 64, 128, 256, 512, 1024, 2048 ... and boom since this is the texture-size limit of ATI cards ;-)
So if you could resize your two background-images to 1024x256 and 64x1024 you would save for those two images 75% of texture memory.

Which card are you using? How much memory does it have?
lg Clemens
i'm using nvidia geforce mx400, with 60 mb of memory.
i've reduced the images sizes to 1024x256 and 64x1024, but they are still not cached... maybe they're just too big?
Offline campbell

Junior Member




Java games rock!


« Reply #29 - Posted 2005-09-30 17:46:57 »

i'm using nvidia geforce mx400, with 60 mb of memory.
i've reduced the images sizes to 1024x256 and 64x1024, but they are still not cached... maybe they're just too big?

Yes, that's good advice from the other guys to try to use power-of-two dimensions.  We still handle non-pow2 dimensions internally, but in most cases we have to allocate a pow2-sized texture, so it can be a huge waste of VRAM if you have a 1066X266 BufferedImage, since that will require a 2048x512 texture (as the others have said).  I think GF2 MX400 has a maximum texture size of 2048x2048, so even your old images have the potential to be cached.

BTW, this is a great resource for finding out the capabilities of all kinds of graphics hardware, like available extensions, texture size limits, etc:
http://www.delphi3d.net/hardware/index.php

Anyway, I think I may know why your image isn't being cached when you use TexturePaint.  In JDK 5, TexturePaint operations will be accelerated by the OGL pipeline, but only if antialiasing is disabled, and only if the image has pow2 dimensions.  This is a reasonable restriction in cases like yours where you are using TexturePaint to tile a background image (AA will be of little use in this case).  So check to see if you have AA enabled when you use TexturePaint, and if so, comment that line  out.

This is covered in my article "Behind The Graphics2D: The OpenGL-based Pipeline":
http://today.java.net/pub/a/today/2004/11/12/graphics2d.html

Note that you could get around either/both of these TexturePaint restrictions by tiling your image manually with drawImage().  But I think the advice given to you so far about using pow2-sized images is useful, and TexturePaint was created for situations like yours, so give it a try and let us know if it helps.

Chris
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.

xsi3rr4x (55 views)
2014-04-15 18:08:23

BurntPizza (53 views)
2014-04-15 03:46:01

UprightPath (66 views)
2014-04-14 17:39:50

UprightPath (49 views)
2014-04-14 17:35:47

Porlus (66 views)
2014-04-14 15:48:38

tom_mai78101 (90 views)
2014-04-10 04:04:31

BurntPizza (151 views)
2014-04-08 23:06:04

tom_mai78101 (247 views)
2014-04-05 13:34:39

trollwarrior1 (204 views)
2014-04-04 12:06:45

CJLetsGame (211 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!