Transparent color

Hi,

Is they a way to specify transparent color?
Dose the graphic context can handle it?

Thx

        Mth

See comment on CoveragePalette class, and I'm moving this to vwnc if you
don't mind as this does not relate to any of the pending builds :)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

The graphic system in VisualWorks does only have support for images
that have fully transparent or fully opaque pixels.  Look at class
OpaqueImage for details. There is no direct support for various
degrees of transparency.

Often your question is asked when people are looking for alpha channel
support. I blogged about "Displaying Alpha Channel PNG Images in
VisualWorks" in this post:

http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Displaying_Alpha_Channel_PNG_Images_in_VisualWorks&entry=3328177749

Runar Jordahl

That's a nice solution, Runar. For some reason I missed it.

The most important application for transparent images in VW would
probably be "smooth icons" or tool bar images and the like. The current
GUI icons tend to look like dated artefacts from the good old days of
Windows 3.1.

You technique could be used to blend transparent icons with the
background of their container and cache the results in  non-transparent
format. However, I'd be glad if VW supported alpha channels at least on
the image level, such that transparent images can be administered like
other GUI resources.

Andre


Runar Jordahl wrote:
> Often your question is asked when people are looking for alpha channel
> support. I blogged about "Displaying Alpha Channel PNG Images in
> VisualWorks" in this post:
>
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Displaying_Alpha_Channel_PNG_Images_in_VisualWorks&entry=3328177749 
>
>

And add my vote for this wish, too.

Thomas

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Tuesday, April 03, 2007 10:59 AM
> To: Runar Jordahl
> Cc: [hidden email]; vwnc-list
> Subject: Re: Transparent color
>
snip
> You technique could be used to blend transparent icons with
> the background of their container and cache the results in  
> non-transparent format. However, I'd be glad if VW supported
> alpha channels at least on the image level, such that
> transparent images can be administered like other GUI resources.
>

Support for alpha transparency can be implemented at three different levels:

- At the Smalltalk level, like I describe.
It is slow, but as mentioned by Andre, caching can be used. To create
for example a toolbar, this would probably perform ok. This solution
should be quite easy to do.

- At the virtual machine level (VM)
The blending would then be done in C. For a task like this, C will
probably perform a lot better than Smalltalk. There were plans to add
transparency at the image level and the name of this project was
"WarpBlt". Some details can be found here:
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Cincom+Smalltalk+Fall+2003+Information
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Cincom+Smalltalk+Winter+2005
There is also an email thread in this group that discusses this issue.
The subject title is: "Finish WarpBlt port [Was: [Feature Request]
CoveragePalette (and alpha blending)]"
WarpBlt has been in Cincom's plans since 2003, but nothing has happened.

- At the GPU-level.
This would probably mean interfacing (from the Smalltalk level) to
some external library (e.g. WPF or Cairo Graphics). This should
perform even faster than the VM-solution. Support for Cairo Graphics
is underway (http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Flying_Cincoms&entry=3351199225)
. This does however not seem be to an official Cincom project yet.


I think that implementing the Smalltalk-level solution makes sense as
a short-term fix. The VM-solution seems to make less sense, since what
we really want is a approach that uses some kind of GPU-optimized
external library.

To me it came as a surprise that when work on Widgetry (Pollock)
started, the underlying graphic system was no rewritten first. I think
that to push VisualWorks forward, the entire product should be based
on a more advanced graphic engine.

Personally I fear that lack of fresh-looking graphical design (both on
the web site and the core product) can prevent new users considering
VisualWorks. Having support for true-color, alpha-transparent images
is needed to improve the look of both VisualWorks itself and
applications written in it. We also need fast drawing of images, a
rich set of graphic elements that can be drawn, anti-aliasing, and
better font-support. More on this at:
http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3332506158

Runar Jordahl

+1

...and not only new users, also long-term users as we are with Moose  
and Mondrian, are thinking to move to Squeak because of missing  
graphical features. As a suggestion, a graphical framework that can  
write to screen, PDF and flash alike would really rock. Also it  
should include animated effects like light, waves and whirls to build  
next-generation UIs. Okay, we are only academia, when we leave the  
ship this does not really hurt Cincom's budget :)

cheers,
AA

On 4 Apr 2007, at 6:24 , Runar Jordahl wrote:

> Personally I fear that lack of fresh-looking graphical design (both on
> the web site and the core product) can prevent new users considering
> VisualWorks. Having support for true-color, alpha-transparent images
> is needed to improve the look of both VisualWorks itself and
> applications written in it. We also need fast drawing of images, a

Runar Jordahl wrote:
> [...]
>
> To me it came as a surprise that when work on Widgetry (Pollock)
> started, the underlying graphic system was no rewritten first. I think
> that to push VisualWorks forward, the entire product should be based
> on a more advanced graphic engine.
One of the major advantages of VW is also one of its major
disadvantages: Being truly cross-platform. This implies identical APIs
for very different OS environments (at least at the image level). Hence
any improvement or major rewrite of OS interfaces at the VM level
involves a dozen platforms, all to be rewritten at the same time. I
understand this is a scaring barrier for a rather small engineering team.

However, as my own experience shows, barriers of this kind always look
bigger than they actually are. A radical major rewrite - once started -
turns out to be a big relief very soon. It's a lot easier to rewrite
code written entirely by oneself, though, even if that was many years
ago. This is not the case with VW.

I highly agree with that. Apart from the language and its compiler(s),
good OS integration and UI performance are the two most obvious things
visible to developers *and* end users at first sight. If I were Cincom,
I'd allocate at least 70% of my engineering resources to these projects
(and dare a radical major rewrite).

Let's face it: The *real* problem is that VAR shops (like mine) need
happy customers, not happy developers. If convenient development tools
can't build products that end users consider satisfactory, sooner or
later we are forced to switch to less convenient platforms (even if it
hurts).

Andre

Andre,

<rant>
I would qualify somewhat the assertion about api. If a feature is
worthwhile, lack of support on every platform should not preclude
inclusion of the feature. Maybe the api is a no-op on unsupported
platforms or raises a DNU UHE (application programmer beware), but we
should not be paralized if we cannot abstract a concept over *every*
platform.

For example, for years there has not even been the basic file capability
in the system of manipulating symlinks on unixy plats, ostensibly
because the concept doesn't map to Win or Mac OS (pre-X). I'd much
rather have had this capability for those subclasses of Filename that
supported the concept than to do without it for so long. Clearly we have
at times allowed the goal of perfect cross-platform abstractions to
overshadow the greater purpose they were created to serve, namely to
support our users.
</rant>

Please take this as a critique of our past performance, rather than your
current comments.

Dave

Andre Schnoor wrote:

Dave Stevenson wrote:

You can also add the sorry state of affairs with the file copy/move on
Win32 platform where that function is in the kernel and way more robust
then VW way of copying(native copy/move preserves file attributes and
ACLs).

Or as far as graphics is concerned - line styles are supported on Win32
for example, but useless in VW while the method name suggests otherwise.

The list of those things is about foot long - and it hurts not only us
developers but general adoption of the VW.

> For example, for years there has not even been the basic file capability
> in the system of manipulating symlinks on unixy plats, ostensibly
> because the concept doesn't map to Win or Mac OS (pre-X). I'd much
> rather have had this capability for those subclasses of Filename that
> supported the concept than to do without it for so long.



Clearly we have
> at times allowed the goal of perfect cross-platform abstractions to
> overshadow the greater purpose they were created to serve, namely to
> support our users.
> </rant>
>
Amen to that.

Heh, it's not that hard to fix copying on your own with,

primCopyFile: lpExistingFileName
to: lpNewFileName
failOnExist: bFailIfExists

 <C: int _threaded CopyFileA( char * lpExistingFileName,
                                        char * lpNewFileName,
                                        int bFailIfExists)>
^self externalAccessFailed

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
we
> > should not be paralized if we cannot abstract a concept over *every*
> > platform.
> >
>
> You can also add the sorry state of affairs with the file copy/move on
> Win32 platform where that function is in the kernel and way more
robust
> then VW way of copying(native copy/move preserves file attributes and
> ACLs).
>
> Or as far as graphics is concerned - line styles are supported on
Win32
> for example, but useless in VW while the method name suggests
otherwise.
>
> The list of those things is about foot long - and it hurts not only us
> developers but general adoption of the VW.
>
> > For example, for years there has not even been the basic file
capability
> > in the system of manipulating symlinks on unixy plats, ostensibly
> > because the concept doesn't map to Win or Mac OS (pre-X). I'd much
> > rather have had this capability for those subclasses of Filename
that your think
> >>> that to push VisualWorks forward, the entire product should be
based
> >>> on a more advanced graphic engine.
> >>
> >> One of the major advantages of VW is also one of its major
> >> disadvantages: Being truly cross-platform. This implies identical
APIs
> >> for very different OS environments (at least at the image level).
> >> Hence any improvement or major rewrite of OS interfaces at the VM
> >> level involves a dozen platforms, all to be rewritten at the same
> >> time. I understand this is a scaring barrier for a rather small
> >> engineering team.
> >>
> >> However, as my own experience shows, barriers of this kind always
look
> >> bigger than they actually are. A radical major rewrite - once
started
> >> - turns out to be a big relief very soon. It's a lot easier to
rewrite
> >> code written entirely by oneself, though, even if that was many
years
> >> ago. This is not the case with VW.
> >>
> >>>
> >>> Personally I fear that lack of fresh-looking graphical design
(both on
> >>> the web site and the core product) can prevent new users
considering
> >>> VisualWorks. Having support for true-color, alpha-transparent
images
> >>> is needed to improve the look of both VisualWorks itself and
> >>> applications written in it. We also need fast drawing of images, a
> >>> rich set of graphic elements that can be drawn, anti-aliasing, and
> >>> better font-support. More on this at:
> >>>
>
http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=tr
ue
> &entry=3332506158
> >>>
> >>
> >>
> >> I highly agree with that. Apart from the language and its
compiler(s),
> >> good OS integration and UI performance are the two most obvious
things
> >> visible to developers *and* end users at first sight. If I were
> >> Cincom, I'd allocate at least 70% of my engineering resources to
these
> >> projects (and dare a radical major rewrite).
> >>
> >> Let's face it: The *real* problem is that VAR shops (like mine)
need
> >> happy customers, not happy developers. If convenient development
tools
> >> can't build products that end users consider satisfactory, sooner
or
> >> later we are forced to switch to less convenient platforms (even if
it
> >> hurts).
> >>
> >> Andre
> >>
> >>
> >
> >
> >

Nothing is hard,
And that is what I ended up doing, anyway (along with
MoveFileA, SetFileAttributesA, GetFileAttributesA,...., etc)

Boris you are missing the point:

The point here -  Those things along with others should be done by
vendor and not done over hundreds of times by me, you and dozens of
other smalltalk developers



Boris Popov wrote: