lessphic? may be a future for morphic

>
> The way I would do your demo in OpenGL would be that every morph
> renders to its own off-screen surface, and when compositing, it would
> apply the non-linear transformation. This is now a standard
> implementation technique, except it usually is not used for projective
> geometry but for fancy effects (like the Genie effect when minimizing
> Mac OS X windows).
>
> Mind I did not understand what you said in the talk, just commenting
> on the visuals ...
>
> - Bert -
>
>

> Bert Freudenberg wrote:
>>
>> The way I would do your demo in OpenGL would be that every morph  
>> renders to its own off-screen surface, and when compositing, it  
>> would apply the non-linear transformation. This is now a standard  
>> implementation technique, except it usually is not used for  
>> projective geometry but for fancy effects (like the Genie effect  
>> when minimizing Mac OS X windows).
>>
>> Mind I did not understand what you said in the talk, just  
>> commenting on the visuals ...
>>
>> - Bert -
>>
>>
> Yes. But you would be doing only a part of it in OpenGL. The  
> geometric deformations would still be needed, but working only on  
> bitmaps. The quality would not be as good (for things like  
> CurveMorphs) because the off-screen surface would have some  
> specific resolution, that could be too coarse for those areas that  
> are enlarged by the non-linear transformation. Think for example on  
> a graph with logarithmic X. Pixels in the off-screen surface would  
> be too big at the left of the graph and too small at the right.

>
> I am beginning to understand your point :) Yes, having that power in
> the base system would be cool. I still think it can be implemented on
> latest-gen OpenGL hardware (which can do the non-linear transform and
> adaptively tesselate curves to pixel resolution) but that then would
> be just an optimization.
>
> - Bert -
>
>
>
>

> On Jan 31, 2008 4:12 PM, Juan Vuletich <[hidden email]> wrote:
>  
>> Better design that current Morphic, with simpler and smaller code.
>>    
>
> What is the appropriate place discuss the class/api/etc. design?  If
> others had an idea about that then they might be able to help
> building.
>
>
>  

> On 31/01/2008, Bert Freudenberg <[hidden email]> wrote:
>
>  
>> I am beginning to understand your point :) Yes, having that power in
>> the base system would be cool. I still think it can be implemented on
>> latest-gen OpenGL hardware (which can do the non-linear transform and
>> adaptively tesselate curves to pixel resolution) but that then would
>> be just an optimization.
>>
>>    
>
> What i'm against, is to bind rendering subsystem to specific hardware.
> There should be a layer, which should offer a rendering services to
> application, and number of layers to deliver graphics to device(s).
> In perfect, it should be able to render itself using any device:
> screen or printer or remote (networked) canvas.
> There also can be a different options in what a rendering media is:
> it's wrong to assume that rendering surface is planar (it can be a 3D
> holo-projector, for instance).
> What is hard, is to design such system to be fast and optimal and
> still be generic enough to be able to render anywhere.
>
>
>  

> >>
> >
> > What i'm against, is to bind rendering subsystem to specific hardware.
> > There should be a layer, which should offer a rendering services to
> > application, and number of layers to deliver graphics to device(s).
> > In perfect, it should be able to render itself using any device:
> > screen or printer or remote (networked) canvas.
> > There also can be a different options in what a rendering media is:
> > it's wrong to assume that rendering surface is planar (it can be a 3D
> > holo-projector, for instance).
> > What is hard, is to design such system to be fast and optimal and
> > still be generic enough to be able to render anywhere.
> >
> >
> >
>
> Morphic 3 is not tied to any hardware! It only assumes the Display in
> Squeak. And it will not be too hard to separate it from the rendering
> engine. Non planar targets could be addressed by a custom coordinate system.
>

> Hi Gulik,
>
> Morphic 3 supports arbitrary non-linear coordinate systems. I don't  
> understand how you envision rendering over those targets. Morphic 3  
> has a rendering engine that renders on Squeak Display, as current  
> Morphic's canvases with Balloon 2D and BitBlt.
>
> Please read my documents, and let's talk about coordinate systems!  
> Currently I have implemented Cartesian, LogX and a few cartographic.  
> Watch the demo at Smalltalks 2007 at http://www.youtube.com/watch?v=90TGhRZUSOo 
>  . It is worth watching even if you don't understand my Spanish.
>
> Cheers,
> Juan Vuletich
>
> Michael van der Gulik wrote:
>>
>>
>>
>> Some time in the next couple of years, I'll need a secure graphics  
>> API for my SecureSqueak project. The basic idea is that I need as  
>> thin a layer of abstraction as possible over various 2-D graphics  
>> targets: X11, MS Windows, Mac, Postscript/other printer APIs,  
>> OpenGL, VNC and possibly libraries such as Cairo. It would also  
>> need to do some event handling, as many events rely on a particular  
>> coordinate system. GUIs such as Morphic or Tweak would run on top  
>> of this.
>>
>> Does your Morphic3 project have a base which could target all  
>> these? So far all I'm seeing is talk about bizarre coordinate  
>> systems.
>>
>> Gulik.
>>
>>
>> --
>> http://people.squeakfoundation.org/person/mikevdg
>> http://gulik.pbwiki.com/
>> ------------------------------------------------------------------------
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. Version: 7.5.516 / Virus Database:  
>> 269.19.16/1250 - Release Date: 1/29/2008 10:20 PM
>>
>
>
>

> And some notes about input.
> Again, morphic should not assume that there are standard input devices
> , like keyboard and mouse, it's should be able to interact with any
> available input devices.
> For this, i think, we should think twice on how introduce different
> events in future morphic system.
>
> For instance, what is the point in having #handlesMouseDown: ,
> #keyDown: methods, when there is no mouse/keyboard on platform (assume
> i run squeak on touchpad)?
>
> These layers should be detached from each other, i think, and morphs
> should react on more abstract (or generalised) events.
>
>  

>
> On Jan 30, 2008, at 12:31 PM, Juan Vuletich wrote:
>
>> - get Esug to sponsor me. If I could work full time on M3, things
>> would go much faster.
>
> How much?
>
>
>> Cheers,
>> Juan Vuletich
>
>> Ps. What do you mean by "the stream of Craig"?
>
> A while ago craig reimplemented a subpart of stream but to use them
> you have to destroy the default library.
> Net result we lost his work.
> Now with Nile this is different you can load Nile and use it if you
> want and migrate from stream to Nile
> when you want. For Morphic 3 I imagine well that event processing can
> be difficult to get m2 and m3 working
> but this was not what I asked. Just the fact that people want to be
> able to load your code in their image.
>
> Stef
>
>
>