Scrolling windows and fixed height slot have a white background -- what about transparent?

[jesset77]

[Edit: cleaning up after some explaination of the defect]

Fixed height containers, at current, unavoidably have a background. _why has hardcoded that background to "white" until the problem can be worked out.

Here is the test code:

Shoes.app do
  background green
  stack :width => 100 do
    border black
    para "Stack #1", :stroke => red
  end
  stack :width => 100, :height => 100 do
    border black
    para "Stack #2", :stroke => red
  end
end

Stack #1 is transparent, Stack #2 is white.

You can deviate from the default with an explicit "background" command, but transparency stops being an option.

[why]

Okay, you're definitely right, but I'm just going paint all these windows white by default until I can get transparency to go. I've spent several hours trying to get it to work on all the platforms and I just can't check in any code until it really works on all platforms.

Everything's white as of [481]. I'm also changing the title of this ticket for my own filing cabinet.

[jesset77]

You could always make a branch for testing fixes to the bug. :) I can checkout from the branch to test WinXP, and I'm sure we've got an OSX and Ubuntu tester up on the list somewhere.

Once we confirm the experimental branch is behaving right on all platforms, then merge back into trunk.

[jesset77]

So looking at the rendered testcases, and thinking about the problem and why a fixed height slot would have difficulty being transparent, I am reminded of iframes in HTML.

Is the problem due to the potential for vertical scroll, and no obvious way to handle transparent scrollable material over a potentially dynamic background?

If so, I have some fascinating cheap seats advice :D (skip if I'm off the mark or you are just tired of hearing from me!)

So I don't know if you are relying on some third party solution for the scrollable features. But assuming that Cairo makes it easy to re-render a rectangle full of geometry on command, you should be able to implement it on your own dime.

I would calculate the flow of the contents of the slot once the parent width is set. Knowing the flow means you know the vertical bounds (top and bottom) of every element in the client-area of the slot. So at any point, only render the contents with vertical bounds that intersect the paint area (reducing memory consumption). Since you are clipping to the slot bounds AND the paint bounds, only the visible bits of such art will be rednered.

Where I'm imagining Cairo must do the grunt work for us is on rendering the elements underneath the slot, and then rendering the slot (or stack of them) all before updating onscreen; thus preventing flicker.

Thots?

[why]

Moved to ditz, ticket #shoes-9. The problem isn't related to computing regions, it's just due to finding the right API calls on each platform to keep the background from painting over what's already been painted. Fixed height stacks are in their own "window" (aka HWND).