Non-X11 version of JUCE?

Dumb question - has anyone thought of the option of having JUCE run without X11, eg: running on DirectFB or some other framebuffer type device?

I donā€™t know anything about directfb, but if you can blit a bitmap to the screen and read back mouse + keyboard events then thereā€™s no reason it couldnā€™t be done.

Would this be for some kind of embedded app?

Possibly - or if you wanted to squeeze more horsepower out of a native system. Iā€™m just entertaining possibilities here. :slight_smile:

Seems like running JUCE on this would just plain totally rock. Fsck X11 compatibility. MIPS!!! Thin is in, bay-bee!

http://www.directfb.org/?path=Main%2FAbout

What is DirectFB?
A new Linux graphics standard

For the special requirements of embedded devices we developed a small, powerful, flexible and easy to use technology for accelerated and enhanced graphics support: DirectFB.

DirectFB is a thin library that provides developers with hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. DirectFB adds graphical power to embedded systems and sets a new standard for graphics under Linux.
Hardware accelerated graphics

DirectFB provides the following graphics operations:

* Rectangle filling/drawing
* Triangle filling/drawing
* Line drawing
* Flat shaded triangles
* Simple blitting
* Stretched blitting
* Textured triangles (perspective correct)
* Blending with an alphachannel (per pixel alpha)
* Blending with an alpha factor (alpha modulation)
* Nine source and destination blend functions
* Porter/Duff rules are supported
* Premultiplied alpha supported
* Colorized blitting (color modulation)
* Source color keying
* Destination color keying

Management

DirectFB has its own resource management for video memory. Resources like display layers or input devices can be locked for exclusive access, e.g. for fullscreen games. DirectFB provides abstraction for the different graphics targets like display layers, windows and any general purpose surfaces. The programming effort for switching from windowed to fullscreen and back is minimized to setting the desired cooperative level.
DirectFB Modules

The API and structure of DirectFB is designed to provide an easy way of implementing the following parts:

* Graphics acceleration (currently Matrox G200/G400/G450/G550, ATI128, Voodoo 3, NeoMagic, Savage and CyberPro)
* Input devices (currently [b]keyboard, serial and PS/2 mice, joysticks[/b])
* Image Provider (currently PNG, GIF and JPEG)
* Video Provider (currently Video4Linux, AVI (using avifile), MPEG1/2 (using libmpeg3), macromedia flash (using libflash))
* Font Provider (currently DirectFB bitmap font, TrueType via FreeType 2)

Well, IMHO DirectFB wouldnā€™t be a good fit for JUCE on the host - thatā€™s why Iā€™d advocate a dual function setup where you could compile JUCE for both X11 and DirectFB. The reasons are fairly simple: Most audio apps are currently built for X11 including stuff like Ardour, Lilypond, etc. etc. Plugins arenā€™t as critical, but ones that arenā€™t written in JUCE would have no clue how to talk to DirectFB. It basically makes a mess of the host platform.

Now where it does get interesting is embedded and super stripped-down systems, as Jules already noted. But, if you wanted to write something like a MOD tracker in JUCE on DirectFB, Iā€™d say go for it. There could be some serious fun had with an environment like that.

So why canā€™t the X11 apps be adapted to DFB? From the DFB description, it sounds like the performance gains could be compelling. Isnā€™t X11 relatively slow because of its ā€œthickā€ client-server architecture?

Confession: Iā€™m not a linux programmer or evan a ā€˜realā€™ user, although I have installed and played with a few different distributions. Iā€™m basically too stupid or lazy to fuxx around for hours getting drivers and settings tweaked.

Just speculating!

Well, itā€™s not a major technical hurdle - programmers would have light to moderate porting work to go from X11 to DirectFB. THe major question is: are the technologies that are available on X11 available to DirectFB? There are tons of toolkits and libraries for X11, and the beauty of X is that they all play nicely together. But, someone might be using widget libraries or toolkits that wonā€™t port over to DirectFB. There are some projects like GTK for DirectFB that make this easier - but it doesnā€™t help applications that use stuff like KDE/QT or any other helper libraries that bolt directly into X11.

Second issue is this: Itā€™s like herding cats in a tuna farm.

Iā€™d be impressed if I could find more than 5 music (either commercial or research) application developers on Linux that I could convince to port their code over to DirectFB and JUCE somehow. Getting open source research types to follow a common direction is harder than taking a gazelle from a lion with only your good charm and a pair of speedos to help you.

Jules might not even be interested in an idea like this, since licensing opportunities for this kind of platform are very few. The company youā€™d want to target for this kind of thing is someone doing host-based plugins or whatnot and wanted to go to the embedded realm and use Linux. DirectFB, since itā€™s so lightweight, is the perfect candidate. The only thing thatā€™s needed besides low-layer code to get JUCE running on DirectFB is some kind of barebones audio layer to talk to whatever you have, and a hardware interface library to talk to various buttons and lights. I can count the number of companies that would use that on one hand.

Regardless, Iā€™m working on this for my own projects / products, and also to answer the question: can it be done? :slight_smile:

All excellent points, Iā€™m sure. Sorry that Iā€™m not really conversant enough in this area to respond in any meaningful way. Iā€™m a JUCE fan, but mostly content sitting waaay up in the nosebleed seats and rooting quietly. The DFB thing just piqued my curiosity.

Good luck with JUCE/DFB.
.
Oh and I enjoyed those colorful similes, they were funnier than aā€¦than aā€¦umā€¦well, something really funnyā€¦ :lol:

Hi Jules
Any news on this thread? Iā€™m interested in having my existing application code base using juce run without Xā€¦ itā€™s for an embedded application Iā€™m working on. Can you give me some hints on what needs to be done to decouple JUCE from X and make it use the linux framebuffer?
Thanks
B

1 Like