You need a GLContext, and call its makeCurrent() method.  I reckon you should be able to create a context through GLDrawableFactory() (either associated with a window, or a pbuffer).

As Saxer says it might be easier to use the event listener approach, although the above approach (immediate mode?) might be better suited for unit testing.

I guess it depends - my suggestion is to use a FloatBuffer internally, and provide an accessor to it (such as 'asFloatBuffer() : FloatBuffer').

Maybe I'm missing something but personally I don't think that this class would ever pose a performance problem.  Are you quite sure this is worth worrying about?

Just a guess, but nowhere in your code snippet do you set the matrix mode, so I wonder which matrix would be modified by your API calls?

[EDIT]
http://www.opengl.org/sdk/docs/man/xhtml/glMatrixMode.xml

That's what I thought, but re-read my earlier reply, it was an order of magnitude slower.  However, if I understand you correctly, you've also tried manually creating a BI using various formats - same poor performance?

I dunno but you might get better performance if you draw into a "compatible" (Component.createImage()) image and blit that into the BI owned by the TextureRenderer.  This would obviously incur an overhead (the extra blit) but might be offset by the faster image format.

Sorry for jumping in, but I'd be curious to know how you create the BufferedImage?  What method did you use, and what format did you specify (if applicable).

The reason I'm asking is because I've noticed mediocre performance with drawing RGBA type BIs, at least in Java 5 (order of magnitude slower than BGRA).  I know this isn't quite what you're doing but maybe the underlying problem (swizzling) is the same?

http://www.glprogramming.com/red/chapter09.html - read this!  Actually, you may want to do some of the NeHe tutorials before you dive into the matter.  I believe someone ported these to JOGL but am too lazy to investigate just now - do your own research... 

EDIT: beware the link I gave you is to a pretty ancient edition of the red book (1.1).  If you are serious about this then you really ought to buy your own, latest is still the 5th edition I think.  Also I wouldn't bother with the blue book as most of its content is online (I love the new OpenGL 2.1 reference pages, http://opengl.org/sdk/docs/man/)...

If however GLSL is not an option then you could still use automatic texture coordinate generation.  Have a look at the glTexGen() OpenGL API.  I just checked in the red book it says, when GL_OBJECT_LINEAR is used then the generation function is a linear combination of the object coordinates.  If you choose appropriate coefficients then you can generate texture coordinates that are simply a function of z.  With a 1-D texture of appropriate colors, you're set.

I hope this helps!

There's no chance your readDataFromGPU() would ever return a non-null value!  You obviously need to allocate the FloatBuffer yourself (there's a BufferUtil class that might come in handy).

 

Am slightly puzzled that the ATI x1300 should be faster than an NVidia 8600.  Also I take it the CPU is an Intel Core 2 Duo @ 2.2GHz, this should be about on par with (or even better than) the AMD 4200X2.

I suppose the results on the MacBook were obtained from running on MacOSX?  Do you have boot camp i.e. could you re-run the benchmark on Windows XP?  Just curious...

Correct.  If you receive an object the interface semantics of which indicate immutability then that doesn't say anything about what could happen in reality.  Which is why immutable types must be final.

There's certainly a case for either approach, but immutable objects are usually easier to live with and less problematic, whereas mutable objects are usually somewhat faster (and maybe a bit more convenient in some situations of limited scope).

A side note on value types in C#, they're probably kinda nice with regards to performance, but they're one reason why C# is quite a bit more complex to use than Java.

If Java 5 is an option then you could save some code and use the Integer.highestOneBit() API instead of your powerOfTwoFloor().

I'm pretty sure that glClear() clears the entire buffer contents, regardless of what projection or viewport you've set up.  Therefore, to achieve what you want, for each viewport you need to draw a GL_QUAD or similar in order to "clear" the background.
http://opengl.org/sdk/docs/man/xhtml/glClear.xml

Well you see, I pointed you in the right direction:
The layout of this isn't compatible with GL_RGBA but GL_BGRA (hence uploading textures is faster, no swizzling involved with the latter).

And as for the image coming up upside down, just play with the coordinates of the primitive that you draw (swap y texture coords) and you're done.

Good luck, you're nearly there!

I'll hazard a guess that you use the Win32 CreateDIBitmap() API.  Are you quite sure that you don't create a 32-bit format bitmap?  I'm asking because the BITMAPINFO structure's bmiColors member is of type RGBQUAD:


If I'm right then your texture format should (incidentally) be GL_BGRA.  Beware that this format requires a certain OpenGL version (1.4??) - there's also an EXT flavour for older versions...

First of all, you must set the texture filtering modes - this would explain why you see nothing.  The following sets nearest neighbour filtering for both magnification and minification:


Inside updateTexture(), use glTexSubImage2D() to update the texture image, (use glTexImage2D() only when you initially create the texture).  This may further improve performance.

Also, before calling glTexSubImage2D() you should set the unpack buffer alignment to 1 (the default is 4, but your samples are 3 bytes R-G-B).  Failure to do so will likely cause the JVM to crash, unless the width argument is always a multiple of 4.


I hope this helps!

[EDIT] With your graphics card, I think you get somewhere near 500MB/sec texture upload speed (pretty much regardless of whether you use RGBA or BGRA on the Radeon 9000, and btw it does not support PBOs).  With that in mind, uploading a 1024x1024 32-bit image (4MB) shouldn't take more than 10ms!
[EDIT2] Turns out I was being a bit optimistic!  I just ran a quick test on my good old Dell D600 (pretty much the same spec as what you use), and I measure a bit less than 20ms for uploading a 1024x1024 BGRA texture.  So that's no more than 200MB/s - a bit disappointing really given that this is actually AGP4x.

My advice is to go with direct NIO buffers.

1. On the Java side, create the buffer of appropriate capacity:

2. On the C++ side, using JNI get the native address of the direct buffer:

3.  On the Java side, create the texture manually, using OpenGL API through JOGL.  Update the texture bits using glTexSubImage2D() - this allows you to pass the direct buffer!
4.  Make sure your texture format is ABGR this is what most gfx cards support natively and is a lot faster than standard RGBA.

I hope this helps!  Texture uploads on an NVIDIA G80 are well in excess of 2GB/sec.  If you want highest throughput then look into Pixel Buffer Objects (PBOs).

[EDIT] I just noticed your image width and height are not powers of 2 - you need to bear that in mind when using straight OpenGL API instead of TextureIO.  Maybe someone who knows TextureIO better than I could comment on whether this could be combined with my above suggestions...

I think that the VM column shows virtual address space that an application has reserved, not necessarily committed.  Committed address space is either mapped to physical memory or paged out.

Bear in mind that a JVM resizing its native heap all too frequently might lead to address space fragmentation - not good for applications that require large contiguous regions say for NIO buffers.  Obviously this is a concern for 32-bit platforms only.

Certainly not a bad idea!   Although, personally I wouldn't worry about a 10ms lag in stopping a thread!  Might be a different story though if you're loading larger images...

BB, you may want to reconsider this.  Surely, the figures stated by tarmo are overall timings.  This means the decoder works at ~6ms per frame, i.e. neglecting I/O this is well over 150fps.  I/O included (say we can do 20MB/sec), assuming the image is 32K large (2:1 compression), and no fancy overlapping I/O, adds another 1..2ms.  In other words, worst case should be around 10ms which is a good 100fps.

The Intel 32-bit architecture (x86) gives a process a 4GB flat address space.  However the upper 2GB are reserved by Windows for shared memory, system libraries, and address space mapped to PCI devices.  So you're pretty much stuck with 2GB unless...

...you boot Windows with the /3GB flag (check your c:\boot.ini file, duplicate the existing entry and add the /3GB switch at the end).  Note however, for an executable to see 3GB it must be explicitly marked as capable of handling the extended address space (clever folks do pointer arithmetics using ints you see...).  This is a linker option in Visual C++ (/LARGEADDRESSAWARE).  Obviously, you don't want to rebuild the JVM from source (maybe you do), however you can alter this flag for java.exe (or javaw.exe, whichever you use to launch your application).  The Microsoft tool that does this is called 'editbin.exe' - I'm sure it's part of the latest Windows SDK or available elsewhere.  BEFORE YOU GO AHEAD and try this I should point out that /3GB is known to reduce system stability, the reduced address space for OS and PCI devices comes at a cost...

Another alternative is to use Intel PAE (Physical Address Extensions) which is like emm386.exe back in the old days - although I think that works only on Windows Server and I doubt the Sun Java VM would support it.

Last but not least, have you considered going 64-bit?  Even if you don't want to run a 64-bit JVM, the 32-bit JVM marked as LARGEADDRESSAWARE would see a 3GB address space...

Hope this helps,
Matt.

PS: Maybe Ken or someone else from Sun would like to comment on how well tested the 32-bit JVM is for this scenario, and why it is not LARGEADDRESSAWARE by default...

Do you rewind the buffer before passing it into glDrawElements?

I can't be bothered to profile but I'll wager to say that...


...modern CPUs should easily branch-predict this one...


...calls to Math.abs() ought to be auto-inlined by the JVM provided your code runs often enough...

If your ints are within the range [-128,+127] then Integer.valueOf( int ) should be used cos that's backed by a cache (looking at the code of a 1.7 JDK, dunno what the situation is with 1.5).

Can you give us more details, how many keys do you typically hold in the map, and what's the value range.  If performance is critical (you want real time) then you could resort to a big lookup table in the form of an Integer[] array with say 64K entries - again this depends on your value range.

And please don't use a WeakHashMap! 

Lovely to see you decided to supply Windows x64 binaries that is a real time saver for us... 

Matt.

Oh in that case please accept my sincerest apologies, I misinterpreted your posting as a statement!

That is plain wrong, NTFS certainly does support files >4G.

FYI - http://en.wikipedia.org/wiki/NTFS

Maybe it's just the pbuffer support that's flakey?  Try using a GLCanvas instead of the GLJPanel if that is feasible for your project, i.e. if you don't rely on lightweight panels.

I haven't tried this, but:

• call getContext().setSynchronized( true )
• launch a worker thread that essentially makes the context current, uploads the textures, and releases the context
• ...to be on the safe side, use synchronization to avoid any operations on the context from the EDT, while the worker thread is busy...
• display a modal wait dialog from the EDT, a reference of which is passed down the worker thread, and is disposed when the worker is finished

That ought to work, good luck!

Glad it works.
I think that in JSR-231, EXT methods were removed pertaining to functionality that was merged into OpenGL up to version 1.3.  Yours is in 1.4 hence the two functions still coexist.

Anyway you should be thankful that you're not running a more decent gfx card  otherwise you might never have spotted the problem in your code!

I believe glBlendFuncSeparate() was introduced in OpenGL 1.4, and is not part of GL_EXT_blend_func_separate!  The Radeon Mobility 9000 supports OpenGL 1.3 only.  Refer to http://www.opengl.org/registry/specs/EXT/blend_func_separate.txt for a detailed specification of the extension you are trying to use.

You are in luck because the GL interface does provide an entry point to glBlendFuncSeparateEXT() (which is what you want to use, according to the link above).

Hope this helps,
Matt.