How Moprhs is rendered

To optimise the DrGeo canvas (get it faster), I try to understand in
detail how is done the rendering of Morphs embedded in a pasteupmorph.
I did not find any detailed information on the Internet about that.
Any pointer?


Right now, DrGeo canvas is a pasteUpMorph, the line, segment, point,
circle, etc. are all Morph added in the pasteUpMoprh. When the model of
a geometry sketch is updated, then all the Morphs view are updated in
one shot (it appeared to be faster than to climb the model tree to
update only the morphs needing update)

Hilaire

--
Education 0.2 -- http://blog.ofset.org/hilaire

On Jul 19, 2011, at 12:46 PM, Hilaire Fernandes wrote:

> To optimise the DrGeo canvas (get it faster), I try to understand in
> detail how is done the rendering of Morphs embedded in a pasteupmorph.
> I did not find any detailed information on the Internet about that.
> Any pointer?

not that I know but I would be interested too.

On 7/19/2011 12:46, Hilaire Fernandes wrote:
> To optimise the DrGeo canvas (get it faster), I try to understand in
> detail how is done the rendering of Morphs embedded in a pasteupmorph.
> I did not find any detailed information on the Internet about that.
> Any pointer?

No such thing. If you're interested in the details you'll have to be
more specific about what aspect you're interested in. Are you trying to
make your graphics faster? In that case enable the preference
#debugShowDamage and have a look at what is drawn when you change your
model. Then add a profiler loop in your model which looks like this:

MessageTally spyOn:[
        1 to: 100 do:[:i|
                self changed. "whatever caused your model to change"
                World doOneCycleNow. "force redraw"
        ].
].

At this point you should have an idea about where to look next.

Hope this helps.

Cheers,
   - Andreas

> Right now, DrGeo canvas is a pasteUpMorph, the line, segment, point,
> circle, etc. are all Morph added in the pasteUpMoprh. When the model of
> a geometry sketch is updated, then all the Morphs view are updated in
> one shot (it appeared to be faster than to climb the model tree to
> update only the morphs needing update)
>
> Hilaire
>

Thanks for the tips Andrea! In between I remembered about reading on
World doOneCycleNow then figure out the use of #debugShowDamage

Hilaire

Le 19/07/2011 17:00, Andreas Raab a écrit :

--
Education 0.2 -- http://blog.ofset.org/hilaire

>> No such thing. If you're interested in the details you'll have to be
>> more specific about what aspect you're interested in. Are you trying to
>> make your graphics faster? In that case enable the preference

Yes, I try to make graphics faster on iPad.
I am tempted to think the bottleneck are the bitblt operations of the
damaged area, also the larger the whole canvas, the slower the rendering
with the same sketch.
I can try to reduce the number of damaged area.

Hilaire


--
Education 0.2 -- http://blog.ofset.org/hilaire

On 19 July 2011 23:28, Hilaire Fernandes <[hidden email]> wrote:
Yes. The fillrate of bitblt engine is quite slow, because all
operations are in memory and CPU bound.
Comparing to fillrate of modern graphics cards. And even to fillrate
of other CPU-driven implementations like, because they using highly
optimized code for that.


> Hilaire




--
Best regards,
Igor Stasenko AKA sig.

On 20 July 2011 02:10, Igor Stasenko <[hidden email]> wrote: (other implementations like: Flash )



--
Best regards,
Igor Stasenko AKA sig.

Le 20/07/2011 01:10, Igor Stasenko a écrit :

This is my felling as well, especially when I compare to GTK+ DrGeo, 10
years ago, the bitblt copy operation of the double-buffering was faster
on computer of that time (800Mhz cpu I guess).
So if optimization should be done, it is on the bitblt plugin, right?

Hilaire


--
Education 0.2 -- http://blog.ofset.org/hilaire

On 20 July 2011 10:13, Hilaire Fernandes <[hidden email]> wrote:
We want to create a vector graphics framework, which eventually replace the old
Canvas and bitblt. Currently its in initial stage of development.
But the idea is to be able to support different rendering backends,
like Cairo, OpenGL or OpenVG.
While application interface will be abstracted from low-level implementation.

Another approach with raster operations which bitblt does is to make a
compiler which generating a highly optimized code on the fly,
using jitter.

> Hilaire
>
>
> --
> Education 0.2 -- http://blog.ofset.org/hilaire
>

--
Best regards,
Igor Stasenko AKA sig.

Le 20/07/2011 14:44, Igor Stasenko a écrit :

That's great and I will be your first client.
Now I am looking for solution in our reach. I have optimize at the image
level, next step should be at the VM level.

Hilaire

--
Education 0.2 -- http://blog.ofset.org/hilaire

On 7/20/2011 14:44, Igor Stasenko wrote:
> We want to create a vector graphics framework, which eventually replace the old
> Canvas and bitblt. Currently its in initial stage of development.
> But the idea is to be able to support different rendering backends,
> like Cairo, OpenGL or OpenVG.
> While application interface will be abstracted from low-level implementation.

I'm sure you're aware of Rome (http://www.squeaksource.com/Rome.html).
It does everything you describe; my original intent was to enable
platform graphics to be used interchangeably with BitBlt.

> Another approach with raster operations which bitblt does is to make a
> compiler which generating a highly optimized code on the fly,
> using jitter.

Been there, done that. Makes very little difference. The problem is that
the time it takes to load and compile BitBlt dominates the time to
actually draw stuff. In my experiments I could see 4-8x improvements for
large area blits but no real world benchmark ever showed any significant
improvements. By the end of the day most time isn't spent filling large
areas; most time is spent in drawing text and other small regions.

Cheers,
   - Andreas

On 20 July 2011 17:08, Andreas Raab <[hidden email]> wrote:
Yes. And it will be one of the backends :)
Hmm.. but why you need to compile every time before use?
Of course there's a lot of combinations for blitting ops
(src depth)*(dst depth)*raster op etc..

but once compiled, you can use it many times.
And actually, Morphic not using all possible combinations, so once you
compile enough operation set its using, then it should run at maximum
throttle,
without compilation interference.
Or maybe we're talking about different approaches?



> Cheers,
>  - Andreas
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 20 July 2011 17:37, Igor Stasenko <[hidden email]> wrote:
And i agree that fill operations is mostly memory-bandwidth bound.
So, using SIMD instructions, is advantageous. I don't have an idea how
to force GCC compiler to use them (i saw that Intel one can do)..
And of course not all platforms having them (we're talking only about
intel-based architectures)..
Just wanted to say that still, there is a space for speed improvement
by couple of factors.

>
>> Cheers,
>>  - Andreas
>>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

With an identical geometric sketch I found the interaction to be much
slower with a bigger playfield (paste up morph).
To be ablsolutely sure, I changed DrGeo code so it only updates the
changed views (morphs), but still it does not improve the speed
rendering (interaction with the user dragging an item), at least on slow
device like the iPad. Funnily I appears to be faster on PC workstation.

Hilaire

Le 20/07/2011 17:08, Andreas Raab a écrit :

--
Education 0.2 -- http://blog.ofset.org/hilaire

On the topic of fillrates and software blitters, has anyone considered
the use of QuickDraw regions to speed up the process? The patent expired
long ago, but the algorithm was designed to allow overlapping windows to
work on the original Mac, and was quite speedy. It was only superseded
by specialized hardware many years later, but still has potential uses
even though no-one bothers to.


L.

On 7/19/11 4:10 PM, Igor Stasenko wrote:

On 23.01.2012, at 08:38, Lawson English wrote:

> On the topic of fillrates and software blitters, has anyone considered the use of QuickDraw regions to speed up the process? The patent expired long ago, but the algorithm was designed to allow overlapping windows to work on the original Mac, and was quite speedy. It was only superseded by specialized hardware many years later, but still has potential uses even though no-one bothers to.


How would that compare to Morphic's clipped top-down drawing, which already is quite a bit more efficient than the usual bottom-up drawing?

- Bert -

On 1/23/12 3:52 PM, Bert Freudenberg wrote: I don't know. QuickDraw regions are basically "sparse bitmps" that are
defined by a clip rectangle + inversion points for the region inside the
rectangle. If you perform a Boolean operation on two rectangles, what
you get is a simple set of inversion points that indicates the start and
end of the resulting irregular region, per scanline. I believe that
simple vector graphics can be designed to make use of the info as well
and in fact, you can make the interior of a line part of a region simply
by drawing into one (if memory serves).

scanlines that are entirely obscured  are not included in the inversion
list, only the start and end points of the lines that are partially
obscured are listed, so it is quite space and time efficient for large,
mostly rectangular areas, but pixel-exact for more complicated regions.
A blitter designed to work with QD regions would simply stop (or start)
copying for the pixels and scanlines that are defined by the inversion
points. The resolution of QD regions was for bitmaps no more than 32,000
pixels on a side (sufficient for any monitor or set of monitors
available even today), but it seems plausible that it could be extended
to 32bit-ish sized pixmaps, given the nature of how the inversion points
are defined --this would double the memory used by the region, however.


boolean operations and a "point in region" operation were designed to be
as efficient as possible and were responsible for the relative
snappiness of early macs compared to PCs running windows.

  Apple stopped using QD regions when they went with PostScript-based
graphics from NeXT, but there are still possible places where they might
be useable. It is conceivable that a version of QD regions can be
created to define 3D ROIs for medical imaging by extending the region
definition to work with stacks of 2D regions in some way, but that's
another thread.

http://www.mactech.com/articles/mactech/Vol.05/05.06/ConvertPict2Rgn/index.html

http://www.computerhistory.org/highlights/macpaint/




Lawson