Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
13 crawler(s) on-line.
 147 guest(s) on-line.
 1 member(s) on-line.


 OldFart

You are an anonymous user.
Register Now!
 OldFart:  37 secs ago
 VooDoo:  7 mins ago
 matthey:  12 mins ago
 pavlor:  26 mins ago
 kolla:  1 hr 25 mins ago
 michalsc:  1 hr 35 mins ago
 amigang:  1 hr 44 mins ago
 gryfon:  2 hrs 1 min ago
 Rob:  2 hrs 40 mins ago
 Birbo:  3 hrs 9 mins ago

Internet News   Internet News : Porter/Duff Image Compositing Article
   posted by Rogue on 26-Aug-2008 12:27:17 (4930 reads)
Since Porter/Duff style image compositing will be part of AmigaOS 4.1, I've decided to try and start a series of articles on the topic. Part one is now up, and can be found here. I want to extend this series in the future, and also go into the programming itself, including sample code.
Read more...



Part one is just a general overview of the concept of Porter/Duff image compositing, with no programming knowledge required. Part 2 will go into the theory of operation and explain the basic usage in AmigaOS 4.1.

Feedback is appreciated.
    

STORYID: 4488
Related Links
· More about Internet News
· News by Rogue


Most read story about Internet News
IBM confirms POWER5 server release details

Last news about Internet News
Tom's Hardware run a story on AMIGA
Printer Friendly Page  Send this Story to a Friend

PosterThread
tomazkid 
Re: Porter/Duff Image Compositing Article
Posted on 26-Aug-2008 13:01:29
#1 ]
Team Member
Joined: 31-Jul-2003
Posts: 11694
From: Kristianstad, Sweden

Nice, tutorials, articles and howto are always appreciated


_________________
Site admins are people too..pooff!

 Status: Offline
Profile     Report this post  
pavlor 
Re: Porter/Duff Image Compositing Article
Posted on 26-Aug-2008 13:34:02
#2 ]
Elite Member
Joined: 10-Jul-2005
Posts: 9584
From: Unknown

Nice!

 Status: Offline
Profile     Report this post  
Kotler 
Re: Porter/Duff Image Compositing Article
Posted on 26-Aug-2008 14:36:35
#3 ]
Regular Member
Joined: 27-May-2005
Posts: 255
From: Sweden

Interesting article!

Keep up the good work.

 Status: Offline
Profile     Report this post  
billt 
Re: Porter/Duff Image Compositing Article
Posted on 26-Aug-2008 18:37:12
#4 ]
Elite Member
Joined: 24-Oct-2003
Posts: 3205
From: Maryland, USA

Cool stuff. Nice to see we're able to treat the graphics chips these days more like what the "custom chip" fans would think we should be doing. While this should be taking some rendering tasks from the CPU, I'm curious how much overhead there is in organizing all the components and sending commands to the GPU telling it what to do. I'm sure this is still a big savings to the CPU's time though. Sounds very cool.

Does this method of things allow GPU to do scaling of items without the overlay? Is the overlay still needed? If not "needed", is it still useful to do an processing in the composition pipeline?

Last edited by billt on 26-Aug-2008 at 06:39 PM.


_________________
All glory to the Hypnotoad!

 Status: Offline
Profile     Report this post  
amipal 
Re: Porter/Duff Image Compositing Article
Posted on 26-Aug-2008 22:59:25
#5 ]
Super Member
Joined: 8-Apr-2003
Posts: 1907
From: Saltdean, East Sussex, UK

Very interesting stuff Rogue - the Cairo stuff sounds particularly useful.


_________________
After a decade away from the scene, I am back!

 Status: Offline
Profile     Report this post  
Rogue 
Re: Porter/Duff Image Compositing Article
Posted on 27-Aug-2008 0:30:31
#6 ]
OS4 Core Developer
Joined: 14-Jul-2003
Posts: 3999
From: Unknown

Overhead for using Compositing isn't significantly higher than preparing a bitmap for blitting. The setup of a full 3D operation is about 80 longsword for the first submit, subsequent operations take less because they only update "dirty" registers.

Scaling is done without overlay. With a bit of effort, YUV textures/bitmaps could be supported as well; right now they aren't because on the radeon 7000, doing a YUV texture needs three TMU's, so a separate alpha mask would not work.


_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Porter/Duff Image Compositing Article
Posted on 27-Aug-2008 17:11:01
#7 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

I dont know wy Porter duff is special announced.
It seem part of Cairo, and when port Cairo then have also Porter Duff code.And here is more detailed what porter duff options are possible.

http://www.cairographics.org/operators/

"""
Normally, you will be using cairo to draw objects on top of each other. But cairo can do differently, if you need it! In fact, you can use all the Porter/Duff compositing operators.

Fourteen different operators are currently available in cairo. This page is a try to describe them. It may contain errors and is possibly incomplete. Please help to improve it!
""""

But a good idea to use Cairo, and when other AOS port too Cairo then AOS is more equal.

Cairo is LGPL this mean everybody can use the source for his own without give the changes back.

currently this backends are here

http://en.wikipedia.org/wiki/Cairo_(graphics)

"""
Cairo supports output to a number of different backends. Backend support includes output to the X Window System, Win32 GDI, Mac OS X Quartz, the BeOS API, OS/2, OpenGL contexts (via glitz), local image buffers, PNG files, PDF, PostScript, DirectFB and SVG files.
"""

I hope that there is working together possible and NOT every amiga system must port Cairo from 0.The Cairo Team have done much much work for getting this.so doing something and dont give back to all, i think is not nice.

If all work in that way, no openspource is possible so no gcc and Linux and maybe no OS4,because all parts from Linux as PPC gcc make utility, must the OS4 team code self.

Apple btw give the khtml code that they use back as webcore.Also the mac kernel is opensource.

maybe there is a sourceforge project possible of a AOS Cairo for all systems

I dont know what Cairo is in OS4 used, but currently Preview release of Cairo is 1.7.4

there are many updates of the project, and i dont know how often OS4 is updatet to make the progress of Cairo usable for Users.

Last edited by bernd_afa on 27-Aug-2008 at 05:23 PM.
Last edited by bernd_afa on 27-Aug-2008 at 05:21 PM.

 Status: Offline
Profile     Report this post  
Rogue 
Re: Porter/Duff Image Compositing Article
Posted on 27-Aug-2008 17:49:54
#8 ]
OS4 Core Developer
Joined: 14-Jul-2003
Posts: 3999
From: Unknown

Quote:
It seem part of Cairo, and when port Cairo then have also Porter Duff code


Yeah, check your facts. Porter/Duff code is not in Cairo, it's a backend thing. Either using pixman (software), Glitz (OpenGL, requires pixel shader support), or your own backend. For AmigaOS 4.1, it's our own backend. Hardware implementations do not write themselves, actually.

Quote:
Cairo is LGPL


Actually, it's dual-license, either LGPL or MPL.

Quote:
I hope that there is working together possible and NOT every amiga system must port


Porting Cairo is no problem. You just compile it. It relies on the backend. That's the more difficult part. The AmigaOS backend relies on OS functionality (namely the Composite call) that is not available on other OSes, and hence is of no use for others.

Quote:
If all work in that way, no openspource is possible so no gcc and Linux and maybe no OS4,because all parts from Linux as PPC gcc make utility, must the OS4 team code self.


I really do wonder what this has to do with the topic. I think it actually has nothing to do with the topic.

Quote:
Apple btw give the khtml code that they use back as webcore.Also the mac kernel is opensource.


This has actually even less to do with the topic.


_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

 Status: Offline
Profile     Report this post  
spotUP 
Re: Porter/Duff Image Compositing Article
Posted on 28-Aug-2008 1:05:25
#9 ]
Elite Member
Joined: 19-Aug-2003
Posts: 2896
From: Up Rough Demo Squad

*KAPOW!* hehehe...


_________________
AOS4 Betatester, Peg2, G4@1ghz, Radeon 9250 256mb, 1gb RAM.

http://www.asciiarena.com
http://www.uprough.net

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Porter/Duff Image Compositing Article
Posted on 28-Aug-2008 14:08:32
#10 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

>Glitz (OpenGL, requires pixel shader support), or your own backend. For AmigaOS >4.1, it's our own backend. Hardware implementations do not write themselves, >actually.

Pixelshader support is usefull and need, so wy not add pxielshader support in OS4.1 and use glitz ?

maybe glitz use pixelshader, but you can mix the porter duff code of other backends(bitmap), and get a own lowend system backend with porter duff, that work without pixelshader.But its really no good idea to use no pixelshader.

Pixelshaders are need, to blur the background.without blur the background transparency look very confused and ugly.

Thats the reason, wy amistart and magicmenu since early beginning do the extra calculation of blur the background behind the menu.
Also all other OS than MOS or OS4.1 do blur the background on transparency windows.

and because OS4.1 support no pixelshader then you must write workaround code.

>Porting Cairo is no problem. You just compile it

When i realy must port Cairo myself, because there is no working together in AOS possible, i of course use glitz with pixelshader support.

Latest winuae have now pixelshader support.

If that dont work, i can use the bitmap backend.
X86 systems have PCIe and newset winuae can transfer 600 MB/sec to gfx Card on my slow amd64 3000+ system and gforce 6600.

i see not yet a problem on high end systems.

but if really is a firefox here, depend on the other libs firefox XMLGUI system etc....

Last edited by bernd_afa on 28-Aug-2008 at 02:19 PM.
Last edited by bernd_afa on 28-Aug-2008 at 02:09 PM.

 Status: Offline
Profile     Report this post  
Rogue 
Re: Porter/Duff Image Compositing Article
Posted on 28-Aug-2008 22:05:27
#11 ]
OS4 Core Developer
Joined: 14-Jul-2003
Posts: 3999
From: Unknown

Quote:
Pixelshader support is usefull and need, so wy not add pxielshader support in OS4.1 and use glitz ?


The AmigaOS 4.1 compositing engine actually uses pixel shader internally. Glitz requires a full OpenGL support. While that is planned, it is not yet done. Doing a custom backend was easier.

Quote:
maybe glitz use pixelshader, but you can mix the porter duff code of other backends(bitmap), and get a own lowend system backend with porter duff, that work without pixelshader.But its really no good idea to use no pixelshader.


I am not sure what you mean. You cannot simply mix backends. You must use one backend that supports everything, or fall back to software. Most of all you cannot simply mix the glitz backend with, e.g. the Win32 or any other backend.

Of course pixel shaders are important, but do you have any idea hwo complex this is to implement? Note this is not just about supporting pixel shaders internally, if you want to have the glitz backend working, you must have the ARB_fragment_shader extension or it cannot do all operators.

Quote:
Pixelshaders are need, to blur the background.without blur the background transparency look very confused and ugly.


Er, no actually that is wrong. You need Shader Model 2.0 (DirectX 9) to do blur with hardware, and even then, a hardware blur is not done by a single pixel shader. You need several passes, using a saparable filter matrix.

A SM1.0 PS cannot have enough instructions to do real blurring. That would in general rule out Radeons before R300 (i.e. Radeon 9500)

Quote:
Also all other OS than MOS or OS4.1 do blur the background on transparency windows.


Actually, AFAIK only Vista blurs the background, and that is because Vista requires a SM2.0 card for Aero. MacOS X certainly does not blur the background (try a shell window), neither does X. I seem to remember a recent patch for Compviz that allows blurring, but only on hardware that supports it.

Quote:
When i realy must port Cairo myself, because there is no working together in AOS possible, i of course use glitz with pixelshader support.


Don't put words in my mouth, please. There hasn't been any decision on how to continue development of Cairo on AmigaOS. Right now, everybody here has other worries.
Yes, we might make our code available at one point. Note: *might* and *at one point*. We do have priorities however, and these priorities lie elsewhere right now (for example an SDK update, just to mention one).

You will "of course use glitz with pixelshader support"? Do you actually *know* what that means? Glitz is a backend that uses OpenGL for rendering, meaning that a) you need a full OpenGL (MiniGL/TinyGL MIGHT be possible) with ARB_fragment_shader support.

Quote:
Latest winuae have now pixelshader support.


From the release notes, it uses pixel shaders for filtering if you run on a DirectX 9 compatible card. It does not seem to support these on the AmigaOS side of things (how would it, it requires OpenGL).

Quote:
If that dont work, i can use the bitmap backend.
X86 systems have PCIe and newset winuae can transfer 600 MB/sec to gfx Card on my slow amd64 3000+ system and gforce 6600.

i see not yet a problem on high end systems.


Pardon my openness, that might be because you don't actually know what you are dealing with.
If things were as easy as you describe them, then why would anybody actually want to use Glitz for hardware acceleration. Why does Vista *require* a DX9 card to enable window transparency effects, if software rendering were fast enough?

Also, Cairo isn't just about transparent windows (shameless plug: read the article ) For a single GUI you might make several composite passes. You might want to upscale something that requires filtering. Filtering is a very expensive operation.

Quote:
but if really is a firefox here, depend on the other libs firefox XMLGUI system etc....


Believe me, if I had the time I would be porting Firefox right now. Personally, I think it is rather easy, only time consuming.


_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

 Status: Offline
Profile     Report this post  
Samurai_Crow 
Re: Porter/Duff Image Compositing Article
Posted on 28-Aug-2008 22:32:51
#12 ]
Elite Member
Joined: 18-Jan-2003
Posts: 2320
From: Minnesota, USA

(off topic)

@bernd_afa

Most SDL programmers on their PCs use OpenGL contexts even on 2d games to speed up their alpha-blending, image rotations, and scaling. Software rendering is about 10-30% slower than hardware.

As for OpenGL on WinUAE, you can use GLitz to reroute the Mesa implementation through the Windows OpenGL drivers but if you're going to do that on Windows, why not just use the Windows version of Cairo and forget the 68k emulation in-between?

I like Amiga but I think emulators are only for old software. For new software you should target new hardware to get better performance. My MicroA1-c is currently loaned out though so I write cross-platform software on my Linux laptop at home and on MacOSX and Windows at work.

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Porter/Duff Image Compositing Article
Posted on 29-Aug-2008 11:53:52
#13 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

>Actually, AFAIK only Vista blurs the background, and that is because Vista requires >a SM2.0 card for Aero. MacOS X certainly does not blur the background (try a shell >window), neither does X.

that mac os blur you can see here below in the thread with a picture. but there are some very old display cards that dont do.

http://forums.macrumors.com/showthread.php?t=378542

i dont understand much from pixelshaders, but when i look on blur effect, it seem enough when the gfx card blit the window contant of the gfx card in half size(bilinear filter) to a temp memory place.then blit the tiles from temp memory that are in background of the half size image with bilinear filter at 2* size.

and i think other know this technique too.when i short look on glitz it seem work without pixelshader too in that way.

http://www.usenix.org/events/usenix04/tech/freenix/full_papers/nilsson/nilsson_html/index.html

""""
In Glitz, convolution filtering is implemented using fragment programs and is only available on hardware with fragment program support. The alternative would be to use OpenGL's imaging extension, which would require a transfer of all pixels through OpenGL's pixel pipeline to an intermediate texture.
"""""

all amiga opengl of 68k support btw the use of an external texture, show a amiblitz program of the nehe opengl demos.

should i post you too linux screenshot that show it blur ?

>I like Amiga but I think emulators are only for old software. For new software you >should target new hardware to get better performance.

yes it get maybe better performance to make native, but use Cairo for a browser is not speedvritical oif GFX funktions.even with DSL, the draw of a page is much less CPU usage than fo the rest of browsing or wait for Network.so i dont want code to winuae native, to get code also on classic amiga working.

but a current PC is fast enough.with jit you loose less than 2* performance, but say you loose 2* performance then you have a 1,6 GHZ 68k CPU on a 3,2 GHZ X86 CPU.

that is enough for many things,
and i like to code my music software in amiblitz, and i like no C.So i code for AOS.
I have only a AMD64 3000+(real 1,8 GHZ) and my songs in hdrec use only 70%-80 CPU load.

but a aone is too slow to play such songs, even if native code is here.

>From the release notes, it uses pixel shaders for filtering if you run on a DirectX 9 >compatible card. It does not seem to support these on the AmigaOS side of things >(how would it, it requires OpenGL).

winuae have always full acsess to native side. there is a winaue program that can use x86 lame and support so encoding of as many streams as you wish(unlimitet multicore support)

problem to use pixelshaders in older winuae is more, the initialisation of the shader engine by winuae screen open and know how to work in winuae surface.But Toni have done this, so there is no reason wy on winuae cant not use pixelshader.

>If things were as easy as you describe them, then why would anybody actually >want to use Glitz for hardware acceleration. Why does Vista *require* a DX9 card >to enable window transparency effects, if software rendering were fast enough?

Wy should m$ write code for software render, if a GFX card with pixelshader own many users.I think PCIe cards all use shader 2.0.

only users that own AGP systems, maybe have no pixelshader.
But AGP is very slow.I know a gforce 6800 AGP User, his mem to gfx Card transfer is only 160 MB.AGP read is very slow, only 2 MB.that simular values as aone

My gforce 6600 transfer over PCIe over 600 MB and read over 380 MB.
A Radeon 800 Card, transfer 900 MB, read not measure.
but both cards are very old, i guess nbew cards transfer more, because high bandwith to GFX mem is also usefull on 3d desktop

Last edited by bernd_afa on 29-Aug-2008 at 12:11 PM.

 Status: Offline
Profile     Report this post  
Rogue 
Re: Porter/Duff Image Compositing Article
Posted on 29-Aug-2008 12:09:39
#14 ]
OS4 Core Developer
Joined: 14-Jul-2003
Posts: 3999
From: Unknown

Quote:
that mac os blur you can see here below in the thread with a picture. but there are some very old display cards that dont do.


The thread says "it's a lame static blur effect". Suppose it's like the menu stuff in AmigaOS 4. The shell window is not blurring its background on an iMac in any case.

Quote:
i dont understand much from pixelshaders,


Yeah I noticed

Quote:
but when i look on blur effect, it seem enough when the gfx card blit the window contant of the gfx card in half size(bilinear filter) to a temp memory place.then blit the tiles from temp memory that are in background of the half size image with bilinear filter at 2* size.


Yes, you can do that. The effect looks crap, though, since the bliniear scaling emphasizes certain directions (mostly the vertical and horizontal). You can do that even with the current implementation on AmigaOS, but it's not worth the effort.

Quote:
all amiga opengl of 68k support btw the use of an external texture, show a amiblitz program of the nehe opengl demos.


Funny, since they are all software only, that does hardly count. The only hardware accelerated Mesa I know of was Storm Mesa, which is quite old and doesn't work anymore. Of course I can compile a software mesa (already did that, and there is one on os4depot too) but that is positively not usable, even on your "high end x86 system".

Ah nevermind. The only arguments you can bring up are "PC is fast enough to do everything in software" anyway. Makes me seriously wonder why the 3D graphics cards are such a fast evolving field, and why anybody would bother.


_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Porter/Duff Image Compositing Article
Posted on 29-Aug-2008 13:03:37
#15 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

>The only hardware accelerated Mesa I know of was Storm Mesa, which is quite old >and doesn't work anymore.

storm mesa work on winuae, hardware accelerate, on my 68060 classic amiga storm mesa work too hardware acceleratet.

>Yes, you can do that. The effect looks crap, though, since the bliniear scaling >emphasizes certain directions (mostly the vertical and horizontal). You can do that >even with the current implementation on AmigaOS, but it's not worth the effort.

i have test, it look ok(other OS do blur more) , but the eye see by the depth unsharp clearly what is in background what is in foreground.

when both is sharp the eye get confuse what is foreground what is bakcground

http://amidevcpp.amiga-world.de/AfA_Screenshots/blur5.png

http://amidevcpp.amiga-world.de/AfA_Screenshots/nonblur.png

>The shell window is not blurring its background on an iMac in any case.

wy you say the shell window ?
I mean when whole macos run (quartz extreme is on), but ok, i own no mac os, but i ask now a mac OS User of a modern mac if windows are transparent and blur or can switch on.

I see no sense of unblur transparency.In magic menu or amistart, there is also no option to switch blur of, for slow system.

So i am in hope Mac OS have blur on transparent wndows too, when the menu is blur.

here is also a link that show, that user want blur and it work on Linux.

http://ubuntuforums.org/showthread.php?t=512622

Last edited by bernd_afa on 29-Aug-2008 at 02:16 PM.

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Porter/Duff Image Compositing Article
Posted on 29-Aug-2008 18:41:49
#16 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

BTW: on aros there is too Cairo.uses software, but i think in PCIe system it is fast too.maybe somebody can tell if in firefox 3 can cairo hardware acceleration switch of, to see the speedlos.on my system i use firefox3.only i notice, load time is very long, but teh speed seem same.

http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=2929&forum=4

 Status: Offline
Profile     Report this post  
[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle