[UI] Just a thought...

Gary Chambers gazzaguru2 at btinternet.com
Fri Apr 18 19:48:54 UTC 2008



> -----Original Message-----
> From: ui-bounces at lists.squeakfoundation.org
> [mailto:ui-bounces at lists.squeakfoundation.org]On Behalf Of Igor Stasenko
> Sent: 18 April 2008 7:32 AM
> To: Squeak's User Interface
> Subject: Re: [UI] Just a thought...
> 
> 
> 2008/4/18 Michael van der Gulik <mikevdg at gmail.com>:
> >
> >
> > On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers 
> <gazzaguru2 at btinternet.com>
> > wrote:
> > > It might be nice that we have some more paint rules in BitBlt. A
> > "fuzz/blur"
> > > effect would be nice and take the load off the Squeak code for such
> > things.
> > >
> > > Just wanting to get more contemporary with the ui look without large
> > > performance penalties.
> > >
> > > Not quite liking the way that effects are hidden behind 
> canvas (leading to
> > a
> > > bloated interface, perhaps (c.f. #drawImage... 
> #drawTranslucentImage...)).
> > > Not sure where the balance should be. Looks like a 
> choke-point that is too
> > > useful to bypass on a case-by-case basis.
> > >
> >
> >
> > If you were to implement some more interesting effects in 
> BitBLT, how would
> > you make sure that Morphs that use this code will still work on other
> > targets such as Rome, Postscript Canvases, VNC etc?
> >

Would need to have fallback options for backends that do not directly support any new features.
Sig, below, seems on the right track in terms of refactoring.


> 1. BitBlt already contains many blitting rules which is problematic to
> support on different back ends.
> 2. In future, i suppose, we need a more functional approach how to
> define drawing operations.
> To describe a blitting/drawing operations with classes/objects not
> with integer numbers, like we currently have, which is meaningless and
> hard to determine how they working.
> 
> Drawing operation should be represented by object -  a
> function(source, destination, arguments..), where function is fully
> reflected in language.
> 

Agree about the operation being properly represented *but* still need the extra performance of a backend (primitive) operation. People are complaining enough that Morhpic is slow...

> 
> > Gulik
> >
> >
> > --
> > http://people.squeakfoundation.org/person/mikevdg
> > http://gulik.pbwiki.com/
> > _______________________________________________
> >  UI mailing list
> >  UI at lists.squeakfoundation.org
> >  http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
> >
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
> 



More information about the UI mailing list