Hi sig,

Make your code available, so we can study your ideas in detail and 
discuss them.

Cheers,
Juan Vuletich

sig escribió:
> Hello squeak-dev,
>
>  during my struggle to make morphic world be OpenGL ready i found
>  that current drawing protocols not providing a freedom in
>  selecting a methods on how the text/images is drawn on display.
>
>  As i can see, the current graphics classes
>  (Canvas/DisplayScreen/Morph) is heavily relying on blitting
>  operations and (wrongly) assume that canvases and/or their display
>  mediums supporting them by default.
>
>  First of all, DisplayScreen is a subclass of Form which is a
>  subclass of DisplayMedium.
>  A DisplayMedium comment reads:
>    I am a display object which can both paint myself on a medium
> (displayOn: messages),
>    and can act as a medium myself. My chief subclass is Form.
>
>  This is wrong. I can give you tons of exapmles when display medium
>  represents a hard copy (take a look at the paper on you desk) and
>  can't be painted on other medium.
>  The printer can be considered as such medium to which you can draw
>  but can't draw a printed contents on other medium.
>  And i strongly presume that the DisplayScreen is such kind of
>  medium.
>  Even more, not all mediums can be represented as rectangular
>  area of pixels. Some of them can be presented as set of vectors
>  (vector displays) or other forms of drawings, and even have
> non-rectangular display surface.
>  And thats where we need a Canvas to draw on it.
>
>  The drawing process by its nature is one way road and assuming that
>  we can freely draw between different mediums is totally wrong.
>
>  So, at abstract level we must think of a Medium to which we can draw
>  by issuing commands through its Canvas. Nothing more.
>
>  To simulate drawings from one medium into another we can use caching
>  canvas, which will collect all drawing commands and then pass them
>  to another canvas of target medium.
>
>  All morphic drawing is built on top of this wrong assumption,
>  which prevents me to make a nice and clean replacement of Display to
>  allow morphs drawn using OpenGL.
>
>  For making this possible there is need to make changes in many
>  places to conform different protocol(s).
>
>  And here is my proposals:
>      Fix the DisplayMedium protocol by revoking assumption that it
>      can be drawn on other medium.
>      DisplayScreen class:
>      - make it a subclass of DisplayMedium, not Form.
>
>      Canvas class:
>      - remove methods which based on assumtion that canvas is drawing
>      on top of Form. Refactor code which assumes such behavior.
>
>      Since canvas represents capabilities of DisplayMedium i think
>      that first references to Canvas must appear there, and any drawing
>      on medium must be a drawing using canvas received from #getCanvas
>      message.
>      The method #defaultCanvasClass must be removed. You cannot
>      connect a canvas to different medium and cannot use two
>      independent canvases for drawing on the same medium because this
>      leads to breaking its current internal state.
>      For caching/clipping purposes there are protocol in canvas itself,
>      which can give you instances for such uses and since they refer to
>      the main canvas, the risk of breaking the medium internal state
> is minimal.
>
>      For example, if morph wants to use a Form to draw itself into (as in
>      Morph>>#imageForm:forRectangle:), then it must
>      directly instantiate a Form and use #getCanvas to draw on it.
>      If there is need in a form having same depth as screen - use
>      Display>>depth. But note, message #depth for DisplayScreen must
>      be considered as a hint, not a part of Form protocol.
>
>      In most cases, drawing in to independent form used for caching
>      purposes, when resulting image is then _blitted_ on the screen.
>      There is a class named CachingCanvas designed specially for
>      such purposes, and showing 0 references in my 3.9 image. Make a
>      conclusion :)
>
>      So, returning back to the needs pre-cached drawing i think the
>      best way is to use Canvas protocol, so it can return an
>      instance of CachingCanvas or its subclass to cache the incoming
>      drawing operations.
>
>      The caching canvas MUST be used by morphs and fonts.
>      Take a look at the TTCFont implementation, i cant look at it without
>      pain.. What do you think, is this the best way of drawing
>      true type glyphs using pre-cached bitmaps?
>      The authors of true type package made a great job by providing
>      TTF's for a squeak, but failed to make it in a really nice
>      fashion when glyphs are coming to draw on the screen.
>      This is another design flaw to which I would like to pay
>      attention. The protocol between Canvas and AbstractFont is need
>      to be redesigned in the way of using CachingCanvas for this
>      purposes.
>      Then there will be no need to introduce own bitmap cache what
>      is currently done in TTCFont class. And moreover, in case of
>      OpenGL a caching canvas is stored in video memory which greatly
>      improves performance when you need to copy it on the screen.
>      Displaying a string is simple set of commands which
>      draw part(s) of cached canvas(es) on the main canvas.
>      Comparing to Form(s), a caching canvas can store a list of
>      commands issued to it, instead of bitmap. And this can reduce
>      the memory usage and greatly improve speed, because of reducing
>      an excessive blitting operations.
>
>
>  I'd like to discuss all above metioned with you :)
>
>  Meanwhile my current implementation of GLCanvas draws a World from 3 
> to 8
>  times faster than current Display. And i think it can be even faster.
>  I think that performance can be increased to such level to make it
> possible to draw
>  entire World in back buffer and still have decent frame rates.
>