Welcome, Guest. Please login or register.

Author Topic: Transparency  (Read 6134 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16882
  • Country: gb
  • Thanked: 6 times
    • Show all replies
Re: Transparency
« on: July 06, 2007, 07:43:06 PM »
Are any of the transparency effects genuine?

As far as I can see, for transparency to work properly, layers.library would have to make sure occluded parts of windows were still drawn and graphics.library would have to support alpha blending for rendering calls. For all this to be quick, ideally you'd need hardware rendering too, since reading back from video ram (ready for software rendering) is like walking in quickset cement on most amiga graphic cards.
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16882
  • Country: gb
  • Thanked: 6 times
    • Show all replies
Re: Transparency
« Reply #1 on: July 06, 2007, 11:45:48 PM »
Quote

motorollin wrote:
Who cares if it's real or simulated, as long as it works and is fast?

--
moto


That depends on what you mean by "works". If you want visible changes to things behind your (partially) transparent window to "shine through" in the same way it does on Compiz/Beryl/OS-X/Vista etc., you need support for it in layers.library and graphics.library, as I said.

If you then want it to be fast as well, then you are ****ed, unless all the RTG drivers get reimplemented to support hardware rendering for the newly added features to said libraries. Doing it in software on existing systems is cringingly slow in comparison, since every pixel in the affected has to be read from the video memory, blended and written back.

In the absence of HW accelerated rendering, the best solution would actually be to have layers.library reimplemented to have a compositor system in fast ram where all the occluded areas can be processed and then the final result written to the display. That still has a big overhead, though its not as bad as reading areas from video, blending them and putting them back.

Either way, you need a lot of work on layers and graphics.
int p; // A