Gustavo Sverzut Barbieri wrote:
> --- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > Ho
>> That's a nice idea, and I tried that. But there are some problems: if
>> we draw overlapping transparent rectangles for blue_round1, we don't
>> want the color to overlapp.
>
> I didn't understant that.
Look at blue1_round1 and go into the movie/mp3/image menu (the normal
one). You see a transparent background for the listing and one for the
view area. These backgrounds overlap (you can see that when you select
an item without image. If you draw these background on different
layers and blit them together, the second rectangle will darken
everything which is below it. Below means the background _and_ the
other rectangle and the space they share gets darken than the rest.
>> But the most important problem: it's too
>> slow. We would redraw most of the screen all the time (areas can
>> overlap) and blitting something is slow, blitting an alpha surface
>> into a surface is very slow. And one very important problem: the
>> areas
>> depend on each other, one has to be redrawn when another changes.
>>
>
> Why? I don't understand.
> What I meant with OPAQUE maybe wasn't very clear.
It was clear. I tried something similar to your proposal. It worked
fine until I got to the view area.
> A Window could be opaque but have transparent areas. The OPAQUE
> thing means we just don't care with things are under this window: we
> don't redraw them.
We can't do that, beacuse ...
> IE: the info area has rounded corners and transparent BG.
... the round corders are part of the background. The small space at
the corners where the round is has to be the original background. And
if the background below that transparent background changes, we have
to redraw the transparent part, too.
> However we know that the screen BG never change. So we can make
> Info.OPAQUE=TRUE.
Wrong. For Aubins new skin the background changes on the main menu for
each item. The background can also change for different folders.
> The same with View and Listing.
The same? View and Listing change, for the view area the background
changes based on the size of the image.
> But the real slow part for us, Menus, will become really fast.
Have you tried my new skin? It's much faster than before. Because
every area is aware of all the others I can redraw only the parts I
want to change.
> About the OPAQUE, I think all the windows could be opaque for now.
That's too easy, it's not the case with the current skins.
>
>> What I have done (with Robs help): the skin is _no_ GUIObject. The
>> skin is only a set of drawing functions. The menuwidget is a
>> GUIObject which fills the hole screen. The menuwidget can be drawn,
>> shown, hiden like all other GUIObjects. It uses the skin functions
>> to draw itself. Since the menuwidget is one GUIObject, background,
>> listing, view, info and title area aren't GUIObjects, they are only
>> part of one GUIObject. With this design I can redraw the changed
>> parts of the skin very fast, it would be much slower (you will
>> notice that even on a fast computer) with separate GUIObjects for
>> each area.
>>
>
> As i said before, I see no reason for that.
I hope you understand now. I tried, it didn't work out. But I don't
see way we should have different GUIObjects for each area. The menu is
one big GUIObject, it's fast and why should everything be an extra
GUIObject?
Dischi
--
On-line, adj.:
The idea that a human being should always be accessible to a computer.
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
