Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (762)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (847)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Which methods from Graphics2D are HW-accelerated?  (Read 2135 times)
0 Members and 1 Guest are viewing this topic.
Offline DD.Jarod

Senior Newbie

Sry for my bad english :-)

« Posted 2003-12-28 19:33:21 »

Which methods from Graphics2D (got with createGraphics from a BufferedImage which was got with createCompatibleImage) are Hardwareaccelerated?
All of them or only drawImage(). And if only drawImage is accelerated, what happens if I call (e.g.) drawLine()?
Is the line drawn on the BufferedImage in the VRAM, or is the (BufferedImage in) VRAM copied to SystemRAM, the line drawn and the result copied back to VRAM?

And what happens if I call setRGB() from the BufferedImage?

And is there absolutely no HW acceleration for linux?
Offline trembovetski

Senior Devvie

If only I knew what I'm talking about!

« Reply #1 - Posted 2003-12-28 22:48:22 »

Simply put, none.

Managed images (those created with create/CompatibleImage) are cached in vram, but all the rendering goes to the surface in system memory (the 'master' copy), and, thus, is unaccelerated (rendering is performed by our software loops).

It's different for VolatileImages: they don't have a system memory copy, and the rendering happens to the surface in vram. Currently (as of 1.4.2) only a small number of rendering primitives is accelerated - drawlines, fillRects, etc (some through ddraw, some through GDI and some via d3d) and copying of other accelerated images to a VolatileImage (and, with a flag,  alpla blending of translucent managed images, using d3d).

The stuff said above is valid for windows. On unix it's different.
First, on unix opaque managed images don't have a system memory copy, they are stored in Pixmaps, and all rendering is done to them using X11 (except for the stuff X11 can't handle, of course). Whether this rendering is accelerated or not, and whether Pixmap is stored in vram, is driver/Xserver dependent.

1-bit transparent managed images, however,  do have  system memory copies, similar to the windows implementation,  and rendering  goes to the system memory copy.

There's tons of other details, you can take a look at this (somewhat outdated) paper

Basically, the idea is that  one should use VolatileImage for images which are modified often (like a back-buffer), and use managed images for sprites and such.

Offline NexusOne

Junior Devvie

Java games rock!

« Reply #2 - Posted 2003-12-30 00:35:52 »

hmmm.. i guess you would be the one to ask... so if i'm just constantly updating an image and want to keep putting the newly-updated image on the screen, how do I work this? I would need to draw other images on the large image for each update, which would involve transparency, but the large image itself would end up totally opaque.. so should I use a volatile image for the large one? and draw bufferedImages onto it or regular images or other volatile images? if I use awt to draw the large image to a window will that slow it down or am I supposed to use awt? sorry for not understanding this very well but i've just been using regular Image objects with a Frame window and suffering through bad performance, and think it's time I improved my code. Just several lines of pseudocode would be really helpful, thanks.  Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DD.Jarod

Senior Newbie

Sry for my bad english :-)

« Reply #3 - Posted 2003-12-30 11:14:37 »

I don't know if it's correct, but this is the way I would do it (dirty pseucdocode):

class Screen extends Frame implements Runnable
BufferStrategy BufferStrat;
VolitaleImage ImgBig;
Grpahics2D GrfxOnBig;
BufferedImage ImgSmall[];

public Screen()
System.setProperty("sun.java2d.translaccel", "true");       // for accelerated translucent  transperency
ImgBig = getGraphicsConfiguration().createCompatibleVolatileImage(Width, Height, true);     // the true for HW acceleration
GrfxOnBig = ImgBig.createGraphics();
ImgSmall = new BufferedImage[NumberOfSmallImgages];
for(int i = NumberOfSmallImgages-1; i >= 0; i--)
     ImgSmall[i] = getGraphicsConfiguration().createCompatibleImage(ImgWidth,ImgHeight,Transparency.TRANSLUCENT);

public void run()
Graphics2D GrfxScreen;
createBufferStrategy(2);     // to get accelerated screensurfaces
BufferStrat = this.getBufferStrategy();
GrfxScreen = (Graphics2D)BufferStrat.getDrawGraphics();

while(ProgRuns == true)
for(int i = NumberOfSmallImgages-1; i >= 0; i--)
     GrfxBig.drawImage(posX, posY, SmallImg[i];
GrfxScreen.drawImage(posX, posY, BigImg);     // draw on backbuffer;      // flipp back- and frontbuffer


and then

Screen MyScreen = new Screen();
new Thread(MyScreen).start();

This is like I approximately made it.
I hope I haven't forgot some part you need.

The BufferedImage I just use because I haven't found a way to make VolitaleImages with Alphachannels.

Someone else some hints?
Pages: [1]
  ignore  |  Print  

EgonOlsen (364 views)
2018-06-10 19:43:48

EgonOlsen (364 views)
2018-06-10 19:43:44

EgonOlsen (304 views)
2018-06-10 19:43:20

DesertCoockie (540 views)
2018-05-13 18:23:11

nelsongames (869 views)
2018-04-24 18:15:36

nelsongames (853 views)
2018-04-24 18:14:32

ivj94 (1304 views)
2018-03-24 14:47:39

ivj94 (425 views)
2018-03-24 14:46:31

ivj94 (1088 views)
2018-03-24 14:43:53

Solater (443 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!