Morphic graphics, Displaying fonts & canvases

Howard Stearns hstearns at wisc.edu
Tue Apr 24 21:31:45 UTC 2007


One might think that this is an already-solved problem.  I don't know.

You might look for comparison at Morgan McGuire's 2D API for Curl, which 
supports a lot of the same goals. He stated these as extensible, 
object-oriented, immediate mode 2D graphics AND text. It facilitates retained 
and 3D API's above and OpenGL below.
    http://www.cs.brown.edu/~morgan/papers/CurlGraphicsThesis.doc
Prof. McGuire later worked with John Hughes' group at Brown, so he may have 
learned something since then that would cause him to reconsider...

sig wrote:
> On 24/04/07, Derek O'Connell <doconnel at gmail.com> wrote:
>> > Since i'm currently drawing a 2d scenes i don't neeed to clip by 
>> depth(Z) value.
>> > But of course for drawing any 3D object i will need it.
>>
>> Excuse me being pedantic but you are still drawing 3D, just flattened
>> by the orthographic projection....
> 
> of course. But by default i set canvas to this type of projection
> because most of morphs think that they draw to 2D canvas.
>>
>> > I draw scene in orthographic projection, and
>> > drawing same figure with different Z values will not make any visual
>> > differences.
>>
>> Of course you can ignore or just throw away z-values but if different
>> they do still affect the rendering, assuming you enable depth
>> buffering. In fact you can get some funky overlapping effects by
>> manipulating the depth buffer.
>>
> i'm aware of that. Enabling depth-test will be in the next stage.
> 
>> > In future, a nice looking perspective projection can be introduced
>> > such that at Z = 0 your object's X,Y will be equal to screen X,Y. But
>> > with Z > 0 or Z<0 will be zoomed in/out relatively to the center of
>> > screen.
>>
>> IMHO it is probably wise to plan for this from the start. For example,
>> when you get to this stage will rotation be desired/allowed? If so,
>> will rotation be restricted to one axis, ie, the z-axis? Makes sense
>> otherwise rotation in the either of the other two axis means widgets
>> dissappear when viewed edge-on unless artificial "thickness" created
>> (as Croquet effectively does with it's "2D" windows) or billboarding
>> used. Another consideration would be managing the extents of the set
>> of objects (limited or infinite-ish space?) and efficiently managing
>> many objects. Other issues would be mipmapping and/or LOD, plus maybe
>> a not so obvious question of suspending objects at a distance? Many
>> issues which you probably already address. Hope I don't overload you
>> ;-)
> 
> Such activities is beyond the Canvas abilities. For nice and effective
> 3D positioning and to restrict some operations (like limit rotating
> e.t.c) there must be some kind of 3D layout manager - a class which
> will establish these rules and makes sure that you follow them. It can
> be a World instance or some kind of Morph3DLayout which draws its
> submorphs in special fashion.
> Its very hard to control all aspects at Canvas level and in fact it
> can limit the features of its potential users. So the less restrictive
> Canvas will be - the better for all of us.
> 
>>
>> By the way, my interests are entirely selfish :-) I hope one day to be
>> freed from the constraints of a dumb 2D desktop and be able to
>> organise myself in a 3D (probably 2.5D) space populated with
>> intelligent objects!
>>
> 
> Same as you!
> Nothing can be better than 2D when you need a plain text reader/editor
> or windows e.t.c. And then if you need 3D, most desktop systems
> require to allocate a rectangular area to draw on it. My efforts
> directed to remove such ridiculos restriction and allow 2D and 3D
> objects coexist in harmony and be managed by same manager without
> extra distinctions.
> 
>> Back to Berts example of a text editor: I accept the depth buffer is
>> not the best way to do clipping. However I wonder if there is an
>> alternative approach where clip-regions are implemented/achieved
>> simply by using rendering-to-texture or FBOs if available? There may
>> be additional benefits? I'm not up to date on OpenGL but regardless of
>> approach I think some degree of gfx memory management will be needed,
>> which leads to...
> 
> Yes, rendering to texture must be allowed. This is very useful when
> morph wants to cache of some of its output. (In fact, to support
> currently implemented shadows/draggable morph contents  its the best
> way to do)
> But still from reasons i showed before, i can't allow to let anyone
> copy canvas. I'll better introduce a good caching protocol, so cached
> surfaces (NOT FORMS!!) will refer to main canvas and will have limited
> protocol, much more restrictive than Form is. For generic Canvas
> implementation we can't assume that cached surface is stored as area
> of pixels (it can be stored as set of commands by example), so
> including behavior which follows such presumption will be absurd.
> 
> premiliary the caching will look something like this:
> | cacheId |
> cache := aCanvas createCachedSurface: extent.
> aCanvas drawToSurface: cache during: [ ... ].
> aCanvas drawCachedSurface: cache at: aPoint. " like drawImage"
> 
> its ok to store a 'cache' var as long as you need it. since all
> drawings to it is controlled by canvas there is no risk of breaking
> canvas internal state.
> 
>>
>> Are you concerned at the moment with the target spec of end-user
>> machines? My interest in 3D environments reached it's peak maybe four
>> years ago and then waned as manufacturers dragged their collective
>> feet and failed to incorporate 3D hw as standard. The situation is not
>> much better today but we can thank MS at least for upping the ante
>> with Vista (I can't believe I'm saying that and, no, I personally have
>> no intention of "upgrading" to Vista). But with plans to add 3D hw to
>> mobile phones and the low cost of cards for desktops the future looks
>> good. Downside is many people now choosing notebooks over desktops and
>> unfortunately many still don't have 3D hw... personally I blame the
>> users for not demanding it :-)
>>
> The target spec is the machine with OpenGL library which can be
> dynamically linked with squeak and used by FFI interface.
> about OpenGL version - this may differ. One assumption that i have
> now, that OpenGL implementation allows creating textures of non power
> of 2 dimensionality.
> Most current implementations of OpenGL (2.0 by default) support this 
> feature.
> The second is rendering to textures.
> I think that this will be enough for my GLCanvas. Any extra OpenGL
> functionality like pixel/vertex shader programs can be used by morphs
> via OpenGL FFI optionally. But GLCanvas functionality will not depend
> from them.
> Or maybe provide some extra protocols which allow safely use such
> capabilities without risk of damaging internal state.
> 

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
jabber:hstearns at wiscchat.wisc.edu
office:+1-608-262-3724
mobile:+1-608-658-2419



More information about the Squeak-dev mailing list