Site navigation

Juce 1.22

General JUCE discussion
#1

…is finally out!

This one’s been a bit of a mission, as I’ve restructured all the image/graphics code so it’s ready for adding acceleration. This means it’ll break one or two bits of your code, but the changes are only small - slightly different constructors for images and a few less methods available in the image class. And if you’re doing any rendering directly to an ARGB image’s internal data, you may need to correct for the fact that they’re now using premultiplied alphas.

Here’s a change list:

* big restructuring of the graphics code to make it ready for adding OS or hardware-accelerated UI rendering. In its current state there aren't yet any accelerated features; some operations will be faster than before (e.g. gradients are hugely faster and much better quality), but other things will be slower as I've not yet done MMX/SSE versions of them. All images are now stored in premultiplied-alpha format, which makes things a bit faster, and this also adds compatibility with things like GDI+. Some changes to the Image class mean that the constructors are slightly different, and you can no longer get a pointer directly to its pixels, instead you need to lock and unlock a section of the image, so that this will also work in future for images that may not be stored in main memory. Annoyingly, after making all these changes, I tried doing a simple GDI+ accelerated renderer, but it ran several times slower than my own graphics routines in most cases, so I disabled it. (if you want to try it out, it's in the juce_win32_Windowing.cpp files). Quartz on the mac should be more promising, so that'll be next.
* new class: AudioFormatManager
* removed any dependencies on DSound.h or DSound.lib so Juce can be built with the latest Platform SDK without needing the DX SDK as well.
* fixed a mac drag-and-drop bug
* made drop-shadows optional for alert boxes + splash screens
* added some fixes for compiling on gcc4.0.2 in mandriva linux

I’ve done my best to make sure all the graphics is working correctly, but I’ve had to rewrite almost every single operation, so shout if anything looks wrong with this version!

#2

Sweet. Everything seems to work fine here. I don’t use images much though.

#3

That’s a good sign!

#4

I found a problem with compiling jucedemo on Mac OS X.

/Users/ring2/src/jucedemo/build/macosx/../../src/demos/PathsAndTransformsDemo.cpp:211: error: 'lowResamplingQuality' is not a member of 'juce::Image'
/Users/ring2/src/jucedemo/build/macosx/../../src/demos/PathsAndTransformsDemo.cpp:213: error: 'mediumResamplingQuality' is not a member of 'juce::Image'
  • And also, ApplicationStartup.cpp is specified by absolute path. :wink:

P.S.
I sent a mail to you for another bug or behavior on Mac OS X with juce v1.22.

Best regards,
Masanao Hayashi

#5

Yes, the resampling quality enum has now moved into Graphics, which is where it should have been all along!

(and I’d swear I already sorted out that absolute path…(?) drat)

#6

Downloaded the latest juce and jucedemo source, jucedemo will not compile, noted part is in the opengl part on line 82 (along with above error):

glTexImage2D (GL_TEXTURE_2D, 0, 4, image->getWidth(), image->getHeight(), 0, GL_BGRA_EXT, GL_UNSIGNED_BYTE, image->getPixelPointer (0, 0));
Something look amiss with the second line? :slight_smile:

#7

after looking at the changes to the Image handling i took note of how functions such as Image::setPixelData were working and modified that line in OpenGLDemo.cpp from:

glTexImage2D (GL_TEXTURE_2D, 0, 4, image->getWidth(), image->getHeight(), 0, GL_BGRA_EXT, GL_UNSIGNED_BYTE, image->getPixelPointer (0, 0));

to:

[code]int ls, ps;
const uint8* imgdata = image->lockPixelDataReadOnly (0, 0, image->getWidth(), image->getHeight(), ls, ps);

glTexImage2D (GL_TEXTURE_2D, 0, 4, image->getWidth(), image->getHeight(),
0, GL_BGRA_EXT, GL_UNSIGNED_BYTE, imgdata);

image->releasePixelDataReadOnly(imgdata);[/code]

which seems to compile and run correctly.

also, under VC++ Express there were a bunch of conversion warnings ( conversions to uint8 ) within the juce_PixelFormats.h file during compile of JUCE 1.22.
a couple of explicit casts to uint8 for each component seemed to clear them right up.

#8

Yeah, I’ll post a new version of the jucedemo today.

Strange that I don’t get any conversion warnings when I compile in VCExpress, but I’ll add some explicit casts too.

#9

Please note that multimon.h is still included by platform_specific_code/juce_win32_Windowing.cpp and that this header is either included in the platform SDK or in the DX SDK.
As I am using mingw (in cygwin), I don’t use the Platform SDK and this include directive is the last dependence to the DirectX SDK.
I tried to comment out the corresponding line from platform_specific_code/juce_win32_Windowing.cpp and it still compiles :!:

I don’t know if it is still usefull on some platforms or if JUCE could get rid of this dependence :wink:

#10

ah, good point! Yes, that line can get zapped. I made it dynamically load the multi monitor stuff ages ago, but forgot to get rid of the include.

#11

[quote=“jules”]…is finally out!

* made drop-shadows optional for alert boxes + splash screens

[/quote]

Ah great ! Is it possible for the menus as well ? (as for my overlay video shadow problem)

#12

[quote=“BlackSun”][quote=“jules”]…is finally out!

* made drop-shadows optional for alert boxes + splash screens

[/quote]

Ah great ! Is it possible for the menus as well ? (as for my overlay video shadow problem)[/quote]

Yeah, that’s easy enough - I’ll add that.

#13

I’ve run into a little problem with the new changes.

before the update i was caching an image of my component by calling graphics::getUnderlyingImage() on the context at the end of my paint() method, and then copying that image to my cached image (which i allocated earlier) using blendimage().

Now, i think both these methods have gone. What would now be the best way to copy an image from a Graphics object to an Image object? (assuming i dodn’t have access to the Image that the Graphics object was created with).

Cheers

#14

Well the reason that it’s gone is that in the future, Graphics objects won’t necessarily have an image - they might render directly to the screen or a printer, etc.

If you need to cache your component, you could use Component::setBufferedToImage(), or just do your painting into a cached image, and draw that to the screen afterwards.

#15

[quote=“jules”]Well the reason that it’s gone is that in the future, Graphics objects won’t necessarily have an image - they might render directly to the screen or a printer, etc.

If you need to cache your component, you could use Component::setBufferedToImage(), or just do your painting into a cached image, and draw that to the screen afterwards.[/quote]

thanks, that second suggestion is what i’m doing now - kinda obvious really - i must have been half alseep when i was looking at it before. :oops:

I originally tried to use the built in buffering code, but i found i didn’t really have any control over when the cached image would be invalidated/deleted - which i kind needed since I very rarely needed to have to redraw the whole component.

#16