Better transparency with UpdateLayeredWindow

[GoogleCodeExporter]

First off: is there anyway for me to set the issue attributes (type,
status, etc)?

Transparent PNGs show up with a magenta background. If you use
CreateWindowEx, you can create a layered window that supports per-pixel
transparency, drawn with a DIBSection and UpdateLayeredWindow:

http://msdn2.microsoft.com/en-us/library/ms633556.aspx

Normally, uses UpdateLayeredWindow requires some changes to the window loop
because of the funny way it deals (or doesn't) with WM_PAINT, but the code
looks like it already does that. Also, since the resampler already
generates 32-bit color, all that is needed is some alpha premultiplication
code.

UpdateLayeredWindow might be able to be used to conveniently do some
effects for slideshows.

Original issue reported on code.google.com by wonchun on 26 Jun 2007 at 4:19

[GoogleCodeExporter]

If it gives you the option to specify "labels" when submitting an issue, click 
in the
label and it'll give you a drop down with type and status options.

I'm not sure what you're proposing here. I'll probably put in code to let you
configure the background color for alpha blend, or maybe allow a checkerboard or
something. I don't really see what the point of using per-pixel transparency in 
the
window is, though. If I'm viewing an image with transparency, I generally want 
to see
the image against a known backdrop (like magenta, or the checkerboard), not 
against
the desktop. Is that what the thing you're proposing would do? And if so, is 
that
actually a behavior you want?

In other words, what effect are you looking for?

Original comment by nothings...@gmail.com on 26 Jun 2007 at 5:15

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm not seeing the "labels" thing...maybe because I'm not part of some special 
group?

I think it might be nice to be able to have a bunch of these windows open
simultaneously (probably as separate processes for now?), and have them all 
composite
on each other, or whatever windows you happen to have open. Like comparing color
swatches or something. Also, UpdateLayeredWindow is nice in that it doesn't 
cause
repaints to occur on windows underneath, even when you move them around.

Original comment by wonchun on 26 Jun 2007 at 6:11

[GoogleCodeExporter]

If you can't set it, don't worry about them; I'll assign them to the appropriate
category, no big deal.

I'm still not really getting it. You open multiple windows, resize them, and 
park
them next to each other to compare. If you want to compare color A in image 1 
with
color B in image 2, AND color A just happens to have transparency next to it, 
then
ok, alpha overlaying them would let you put them right next to each other to 
compare.
But that doesn't seem a very common case to me, compared to all the cases where 
the
images aren't transparent or the interesting color isn't next to a 
transparency. It
just doesn't seem the right tool for that job in general, and so I'm not sure 
why
it's worth adding this feature to catch a small subset of the cases.

To me, imv(stb) is about letting you view image files, and communicating to you 
about
what is in the image file. Hence the way the border is set up for guaranteed
contrast, bound the image unambiguously if the window aspect ratio is 
different, and
the alpha-blend-over-a-known-background.

(You can already run multiple imv(stb)'s at once. They're totally separate 
processes,
so they don't share a common image cache, but I doubt I'm ever going to tackle 
fixing
that.)

Original comment by nothings...@gmail.com on 26 Jun 2007 at 6:35

[GoogleCodeExporter]

Original comment by nothings...@gmail.com on 27 Jun 2007 at 9:13

• Added labels: Priority-Lowest
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I know you can have multiple instances open. In fact, that's what gave me the 
idea.
It's not so much a "compare two images" kind of thing as let me do a "paper 
doll"
thing without having to load GIMP. Basically, you can see what a bunch of images
might look like composited on each other.

I don't think it would be hard or burdensome to have multiple transparency 
modes.
"transparent" could just be a special case of "solid color." 

Original comment by wonchun on 27 Jun 2007 at 9:29

[GoogleCodeExporter]

Ok, the problem is, where do we draw the line? If we just keep adding features
because it would be nice to have, we'll eventually end up [i]with[/i] Gimp!

So I need a compelling description of the utility of the feature as a viewer, 
not as
a lightweight editor. Like, what's the use case where this is part of your 
workflow
but isn't redundant to some other software?

Original comment by nothings...@gmail.com on 27 Jun 2007 at 10:42

[GoogleCodeExporter]

This might just be a toy feature; I just don't think it would take very much 
work,
and might make it fun to play around with. In fact, I'm probably just going to 
do it
this weekend. I'll submit a patch or something?

Original comment by wonchun on 27 Jun 2007 at 11:31

[GoogleCodeExporter]

Won, I just wrote up the details on why I'm being anal about features I think 
are
questionable. Go to the wiki and look at 'FeatureRequests'.

Original comment by nothings...@gmail.com on 27 Jun 2007 at 11:38

[GoogleCodeExporter]

I've added a detailed description of why I think doing this
right is a lot harder then you think, and why solutions short
of that would be unacceptable to me.

http://code.google.com/p/stb-imv/wiki/RejectedRequestExample

Please don't take this as browbeating; my intention isn't to
pick on you, or pick on this feature in particular; I just want
to forestall a bunch of possible future requests by using this
one as an example into my thought processes. If you disagree with
my analysis feel free to comment there.

Original comment by nothings...@gmail.com on 28 Jun 2007 at 2:37

[GoogleCodeExporter]

I can't actual comment on the wiki page; I think I need special permissions to 
do
that, or just better glasses to see where I'm supposed to click.

I think this discussion is helpful. I certainly respect your desire to squash 
feature
creep (creeping featurism?), and I won't pursue this too hard.

A few points, though:

The GDI+ thing, mentioned in the forum, was just to easily accomplish image 
loading.
I wouldn't expect GDI+ to do scaling/compositing in any particularly desirable
way...although it does do bicubic.

You shouldn't need to change any SetWindowPos/MoveWindow calls. 
UpdateLayeredWindow
doesn't change the position unless you tell it to. AFAIK, you're basically just 
doing
all your work in a DibSection's memory, and then calling ULW instead of
SetDIBitsToDevice. And you can always use a 32-bit or 24-bit DibSection, and 
ULW will
do the right thing.

ULW has the advantage that it doesn't cause repaints, and doesn't need repaints 
from
window covering/reveals. So it may be better in terms of "interactive 
performance"
(i.e. dragging images around). Also, the desktop compositing can be hardware 
accelerated.

The "is desktop alpha on" state would just amount to a background color. Right 
now it
is magenta. I'm proposing that you allow people to chose "clear." So, this would
force you to do compositing every time you render, but do those two extra 
multiplies
really hurt you that much if you're planning on doing bicubic?

I guess most of your issues are about performance and memory overhead, and 
being able
to render directly out of the different image formats so that you don't 
needlessly
convert to 32-bit. Well, metaprogramming could certainly make that easy, but 
maybe
that (very reasonsably) violates your "maintainability" clause.

Original comment by wonchun on 28 Jun 2007 at 3:14

[GoogleCodeExporter]

Re: GDI+ you're right, I confused those two once I started writing the article. 
I'll
welcome a GDI+ patch, and split it into two projects as I described, so we can 
A/B
them. (I'm gonna change the page to remove the mention of GDI+)

Re: changing the SetWindowPos calls, I thought the docs for UpdateLayeredWindow 
said
you're supposed to call it when you change the window position. I might have 
misread
it, I was only skimming.

>ULW has the advantage that it doesn't cause repaints, and doesn't need 
repaints from
window covering/reveals. 

This is an advantage _and_ a disadvantage; it has to keep memory for the window 
and,
presumably, backing store for what's under the window. (What are all these 
reports I
keep hearing about Vista not running well with only 1GB of memory? I prefer 
buying
RAM to have more memory available to _my applications_, not to eye candy!) 
Moreover,
my code [i]is[/i] already keeping around a bitmap to repaint with, so 
repainting is
about as fast as it can be. The only faster windows could do it is better HW
acceleration; which I assume in the non-alpha case it won't do any better.

>So, this would force you to do compositing every time you render, but do those 
two
extra multiplies really hurt you that much if you're planning on doing bicubic?

Under my model, it's _two unnecessary multiplies_! When I wrote the bilerp 
resampler,
I went ahead and optimized it to use 2 multiplies per 3-color lerp, instead of 
3--net
savings of 3 multiplies. (And I may try to squeeze out one more.) So, yeah, if 
I'm
going to go to that effort to optimze it, it bugs me to de-optimize it for a 
feature
I don't want or need.

And yeah, template metaprogramming is an ugly hack; there's a post on the
molly-rocket forum that illustrates one of the hidden costs of using it
(incomprehensible errors). And it leads rapidly to executable bloat. (Plus I'm 
using
C, not C++, and I'd prefer not to switch, nor introduce a dependency on some 
other
metaprogramming tool.)

Original comment by nothings...@gmail.com on 28 Jun 2007 at 4:14

[GoogleCodeExporter]

Original comment by nothings...@gmail.com on 18 Jul 2007 at 12:24

• Changed state: WontImplement