<br><br><div class="gmail_quote">On Feb 1, 2008 7:21 AM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 31/01/2008, Bert Freudenberg &lt;<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>&gt; wrote:<br><br>&gt; I am beginning to understand your point :) Yes, having that power in<br>&gt; the base system would be cool. I still think it can be implemented on<br>
&gt; latest-gen OpenGL hardware (which can do the non-linear transform and<br>&gt; adaptively tesselate curves to pixel resolution) but that then would<br>&gt; be just an optimization.<br>&gt;<br><br></div>What i&#39;m against, is to bind rendering subsystem to specific hardware.<br>
There should be a layer, which should offer a rendering services to<br>application, and number of layers to deliver graphics to device(s).<br>In perfect, it should be able to render itself using any device:<br>screen or printer or remote (networked) canvas.<br>
There also can be a different options in what a rendering media is:<br>it&#39;s wrong to assume that rendering surface is planar (it can be a 3D<br>holo-projector, for instance).<br>What is hard, is to design such system to be fast and optimal and<br>
still be generic enough to be able to render anywhere.<br></blockquote></div><br><br>For the holo-projector example, you need &quot;architecture&quot;. For example, consider this ASCII-art layered architecture for a GUI:<br>
<br>&nbsp;&nbsp; &nbsp; Application<br>&nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp; &nbsp;&nbsp; ToolBuilder<br>&nbsp; &nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; \<br>2-D Widgets &nbsp;&nbsp;&nbsp; 3-D Widgets<br clear="all">&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>Canvas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OpenGL or something<br>&nbsp; |<br>BitBlt, Cairo, etc.<br>
<br>Of course, there&#39;s a lot more to it. I believe (and I&#39;m putting words in Juan&#39;s mouth here) that Morphic 3 is primarily a 2-D GUI.<br><br>In terms of hardware support, the Canvas class (currently used by Morphic for drawing everything) needs to be rethought. I&#39;ve got a preliminary brain dump here: <a href="http://gulik.pbwiki.com/Canvas">http://gulik.pbwiki.com/Canvas</a>. Morphic 2 (i.e. in Squeak now) isn&#39;t very smart about how it draws stuff; it&#39;s very slow. BitBlt is capable of a lot more. Also, the underlying layers of architecture (BitBlt particularly) aren&#39;t smart about rendering. The X Windows implementation of Squeak for example (AFAIK) only uses a single bit-mapped &quot;window&quot;. The X Window system can do a lot more, such as vectored graphics and multiple windows. <br>
<br>I suspect that the VNC implementation doesn&#39;t cache bitmaps on the client, although this is pure speculation.<br><br>I would change Canvas by:<br><br>- Allowing a canvas to have movable sub-canvases. These would map 1:1 to &quot;windows&quot; (i.e. drawable areas without borders, title bars) in the X window system, or cached bitmaps in VNC, or display lists / textures in OpenGL. These could be moved around the screen easily by only changing the location of the sub-canvas.<br>
<br>- Canvases could be implemented as bitmaps or vectored graphics/display lists; the application doesn&#39;t need to know what implementation is actually used.<br><br>- Introduce a &quot;needsRedraw&quot; system of some sort. A Canvas implementation may or may not cache its contents (as a bitmap or vectored graphics/display list). Various implementations may discard the cached contents at times, or perhaps not even cache content.<br>
<br>- Use micrometers rather than pixels as the unit of measurement and provide a &quot;pixelPitch&quot; method to return the size of a pixel. For example, my screen has a pixel pitch of 282 micrometers. A 600dpi printer would have a pixel pitch of around 42 micrometers. You could use a SmallInteger to store micrometer values.<br>
<br>- Introduce, somehow, an event system closely coupled to a Canvas (because some events have coordinates relative to a canvas). <br><br>- Somehow support remotely cached bitmaps. I haven&#39;t thought about this yet.<br>
<br>Gulik.<br><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>