SciTech Software, Inc. today announced a collaboration with Trolltech AS to provide desktop quality 2D graphics acceleration and great chip level compatibility for embedded Linux developers. As part of the announcement, SciTech has released SNAP Graphics IES for Qt/Embedded, Trolltech’s embedded Linux GUI toolkit. Additionally, Trolltech now provides built-in support for SciTech SNAP.
Trolltech Gets 2D Graphics Hardware Acceleration for QTopia
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I was getting all excited that KDE would possibly be video-hardware accelerated Quartz-style till I saw that it’s only for the embedded platform.
I guess I’m just going to have to wait for XFree to start coding the acceleration or wait for nvidia to release framebuffer support so I can use XDirectFB.
Huh? XFree does support 2D acceleration. It might not be implemented in the driver, but it’s generally available.
… why should I use snap from scitech?
It would be nice if X responds to lower clocked machines like WinXP/2k did!
Only on a 1ghz-up machine, KDE runs really nice and it’s nice to work with it!
Hehe, and I thought I was picky about desktop responsiveness. I use Gnome & KDE on an Apple iBook 800 MHz, Radeon 7500 with no official drivers, just xfree-drm radeon drivers. It’s not snappy but I’m not complaining…
From what I read, with Qt 4 coming up Trolltech will be focusing on optimizing it for less bloat. This focus makes sense for embedded purposes but the desktop Qt liraries will inherit this as well, afterwards the KDE team will inherit from it and hopefully take a similar approach and slim KDE down.
Huh? XFree does support 2D acceleration. It might not be implemented in the driver, but it’s generally available.
Yes I’m aware of that. I was talking about having full desktop acceleration like the Quartze engine in OS X or the upcoming(?) DirectX accelerated desktop of Longhorn.
Canopy Group owns 5% of Trolltech.
Switch to Gnome and dump KDE until Trolltech/QT dumps Canopy.
Why would I switch to a POS toolkit that is a bitch to program for when I can use one that provides easy app integration, UI consistency…
Qt is GPL and there’s nothing that Canopy can do about that. Esp. as a very small minority shareholder.
@Blake: Microsoft owned 5% of Apple? What’s your point? Canopy group is just an investor — TT is a private company whose employees have the majority share and do not have any share holders to answer to.
@Nacs: For the last time! Quartz is not accelerated! In fact, its mostly software rendered! For once, Apple put out some decent tech docs about Quartz “Extreme.” Why does nobody read them?
Ok, I will bite. What specifically makes you believe that Quartz Extreme is not accelerated? It is; I use it every day at home and it is very fast and snappy.
If there are docs indicating this is not the case, point me at them and I will be happy to read up some more on this technology.
Apple’s Quartz Extreme Siggraph presentation specifies this clearly. If you look at page 10 of the PDF, you can clearly see Quartz2D drawing being done via software, while only compositing (window-transparency effects) are accelerated via hardware. So its accelerated, but not in the same sense as Longhorn. Heck, its not even accelerated in the same sense as X11 or Snap — because Quartz 2D is AA’d by default, pretty much the only 2D acceleration it can use is bit-blitting. This is okay, because most OS X apps don’t really take advantage of the Quartz 2D engine. Most stuff is still bitmaps, so it still feels pretty fast.
The link is split so as to not mess up Eugenia’s page layout
http://www.opengl.org/developers/code/
features/siggraph2002_bof/sg2002bof_apple.pdf
I will take a look at it. It would be very surprising to me if this is the case in actual driver implementations, since hardware can easily render into offscreen video memory regions. I will let you know what I think after reading it 😉
Ok, I read the PDF. I am not sure I entirely believe that what the PDF says is 100% accurate. They list that QuickTime renders in software to a surface which is then composited in the Quartz compositor also, which is not correct either. In order to achive high performance MPEG/DVD playback, the Radeon and NVIDIA chipsets have hardware motion compensation and inverse discrete cosines. In order to be able to utlitise those sections of the video pipeline, the hardware will be involved in the MPEG video decoding process, so the ‘software’ arrow in this case is not really true. Hence I also don’t believe that Quartz2D does everything in software. Filling a rectangle is real easy, and I am sure that at least basic stuff like that (which is not affected by AA) would be done in hardware to the window compositing buffers.
My $0.02 anyway 😉
There are very large synchronization issues involving simultanious CPU and GPU rendering to the same buffer. Its quite a hastle to do and not often done. This is why, by the way, that neither DGA, nor BDirectWindow, nor DirectDraw allow you to draw hardware accelerated primitives into the same graphics buffers that you have a direct pointer to. Its certainly possible that Quartz2D does this, but:
a) Would Apple *ever* lowball (rather than exaggerate) their system capabilities?
b) There is no evidence of it.
Ok, now it is clear you have never programmed graphics hardware ;-). Not to be rude, but your statement that:
“This is why, by the way, that neither DGA, nor BDirectWindow, nor DirectDraw allow you to draw hardware accelerated primitives into the same graphics buffers that you have a direct pointer to”
is completely false. You can do this under DirectDraw (via a DirectX surface lock) as well as with DGA. I don’t know about BDirectWindow, but if this was not supported that is pure oversight on Be’s behalf. In the case of DGA, it has accelerated primitives and it allows direct access to the video memory surface. The only requirement is that when you have done something using the hardware if you wish to now do something in software, you have to do a DGASync() operation before directly accessing the video memory. This operation ensures that any hardware requirements are satisfied, usually that the engine is idle before allowing the software to proceed.
Sure there are overheads to doing this, but they are a lot lower than doing *everything* entirely in software. Correct arbitration between graphics hardware rendering and software rendering is a simple and standard operation ;-).
BTW, your statement about not having direct access to the same buffer does hold true for the DirectX 8/9 API’s, where Microsoft tried to simply things somewhat for ‘high end 3D hardware’, but at the end of the day the same DX8/9 drivers still need to support the DX7 interface’s, which fully utilise the DirectX video memory locks (which is what SNAP on DirectX uses for that reason).
Actually, haven’t done any DirectDraw programming since the DDraw/D3D merge. From what I remember of DirectDraw, there was no way to use any accelerated primitives with direct contexts. You could use the locking functionality to get bit blits, but you didn’t get any HW accelerated lines, squares, trapazoids, etc.
You got hardware rectangle fills and BitBlt’s (including transparency, etc), but you didn’t get any standard GDI stuff like lines, polygons etc for the DirectDraw components. There is nothing to stop Microsoft from having enabled this, but they didn’t want to make it too complicated for the IHV’s to write the DirectDraw drivers.
So basically you could use the hardware for fills and blits (sprites etc), but everything else you did in software. All of this happens to the same offscreen video memory buffers, and you use the lock functions to ensure that the hardware is ready for software rendering when necessary.
SNAP on the other hand (especially when used via MGL) can accelerate a lot more stuff than DirectDraw does, including lines, text, polygons and more, and you can mix and match hardware and software all on the same rendering buffer. MGL uses the MGL_beginDirectAccess() and MGL_endDirectAccess() functions to wrap your own custom software rendering functions (internally this is managed automatically when MGL/SNAP primitives are done in software rather than hardware).
This is why, by the way, that neither DGA, nor BDirectWindow, nor DirectDraw allow you to draw hardware accelerated primitives into the same graphics buffers that you have a direct pointer to.
You can draw GDI primitives onto a directdraw surface I think.
Canopy is the parent company of SCOX and Trolltech. Don’t let TrollTech fool you. Yarro (CEO of Canopy) sits on the TrollTech’s board of directors. TrollTech owns 1.5% of Scox, and probably several other Canopy companies.
TrollTech is trying to distance themselves from scox. Saying they don’t agree with scox’s present course of action.
I say: actions speak louder than words. I’ll believe trolltech when trolltech divests themselves from canopy – not a minute before.
Canopy is the parent company of SCOX and Trolltech. Don’t let TrollTech fool you. Yarro (CEO of Canopy) sits on the TrollTech’s board of directors. TrollTech owns 1.5% of Scox, and probably several other Canopy companies.
TrollTech is trying to distance themselves from scox. Saying they don’t agree with scox’s present course of action.
I say: actions speak louder than words. I’ll believe trolltech when trolltech divests themselves from canopy – not a minute before.
Actually I’ll have to back Rayiner here. Quartz is generally not HW accelerated, rather apps render via SHM segments into a backing store entirely in software which is compressed and decompressed on demand. The resultant toplevel windows are then composited, using hardware if QE is enabled.
Because the backing stores are not (afaik) rendered into video memory, it’s pretty hard to use HW acceleration there.
On DirectX – in previous versions of DX yes, you could combine some GDI ops with direct access, however that ability was stripped in DX8 I think, due to Extreme Pain caused both to MS and driver developers. Generally you cannot mix CPU and GPU access to the video buffer without some form of locking.