Just want to confirm it works here on my A1XE :) Well, it works on my PCI RadeonHD anyway. Crashed solid on the 9250, but I expected that. Messes up the display a bit but that's just because I'm using prehistoric RadeonHD drivers (I was a betatester but now need to buy the driver to show Hans support - as soon as a I get my X1000 up and running the driver is on my shopping list!)
The spinny animation thing when you launch an app does look rather like evidence of a coder having fun playing around with graphics routines :)
Managed to solve the alpha bitmap rendering issue, but the result is, that it is now unbearably slow, even on an X1000... I think the problem is, that the blitting routines somehow reverts to software rendering under some circumstances. It is a tad bit frustrating, I have to admit.
I wonder why docks insist on zooming in under the mouse pointer. I know perfectly where my mouse pointer is. I don't need the dock to help me finding it
@elwood Because it just looks cool and fancy and not static as from stone age. Besides i assume there can be many different effects later between which you can choice, as well as disable them if you don't like them and prefer static stuff.
@alfkil Cool stuff ! Sadly i with radeon9250 on my peg2, so no luck too. But after wathing vid have few questions:
-- did you want to make it as some sort of replacement for amidock ? If yes, then dockies will works in it ? Or it will be just as "launcher" panel ?
-- is there options to set size of the dock in your implementation (so i can put it to title bar of wb for example). If you have interst to add one later, will be cool if sizing will also resize everything inside: be it icons, be it rendered data to dock (in case if you will support dockies later).
-- is there options for auto expanding of dock not only from left to right, but also from right to left ? With amidock there is problem now: if i move my dock close to the right side, and add some new docky to, its then just create one more line, but i just want to make it expands to the left side instead.
I know its usuall "i wish everything" , but if someone at least want to make modern version of amidock, i am fully up for help/tests/donations.
You can place your dock (or even have many separate docks) on every edge and every corner of the screen. The dock will always be centered, though. You can adjust the maximum and minimum size of the icons dynamically, and the dock is automatically resized when you add/remove icons.
I am planning to add full suport for appdockies and subdocks (not sure entirely how to construct the later, but I guess I will find out).
I will post a version that works on old Radeon in a few minutes. Don't try the String render mode, though, it is unbearably slow...
I agree with Hans : What are you trying to do with "CompositeTags from drawing TO alpha8 bitmaps" ???!??
I'd be interested to know the exact details too. My guess is that he's using it render scaled versions of the alpha channel to the window's alpha mask. CompositeTags() offers the only HW accelerated scaling (and rotation), so it's the only function that could do something like this at speed.
AFAIK, a window's transparency is always controlled by a mask/clip-region, even if the window's own bitmap is an RGBA8 one.** That makes rendering to alpha8 bitmaps critical to getting something like BananaBar working.
As weird as "compositing" to an alpha8 bitmap is, it looks like it would serve a good purpose, so maybe it should become officially supported.
Hans
** If I'm wrong, and it is possible for a window's transparency to be controlled by its own alpha channel, then please tell me how it's done.
Managed to solve the alpha bitmap rendering issue, but the result is, that it is now unbearably slow, even on an X1000... I think the problem is, that the blitting routines somehow reverts to software rendering under some circumstances. It is a tad bit frustrating, I have to admit.
How did you solve it?
BTW, you can suggest enhancements and submit bug reports over on Hyperion's support forums. If you give exact details on what isn't working as it should, then it could be improved in a future update.
I just render to a RGB32 bitmap with both color and alpha, and then I use BltBitMapTags() to copy to an alpha8 bitmap (the clipRegion). Seems to work, but there are some strange problems with speed, so I am interested to know, if it is possible, that the BltBitMapTags-call (from RGB32 to ALPHA8) will somehow revert to software rendering.
EDIT: Tried using a RGB32 as destination as well (linked to by the ClipRegion), and that actually seems to work as well. Still the speed issue persists, so there is the possibility, that I have run into some issue with the window clipping. Hmm.
I just render to a RGB32 bitmap with both color and alpha, and then I use BltBitMapTags() to copy to an alpha8 bitmap (the clipRegion). Seems to work, but there are some strange problems with speed, so I am interested to know, if it is possible, that the BltBitMapTags-call (from RGB32 to ALPHA8) will somehow revert to software rendering.
Any blitting that involves pixel format conversion is software only.