Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

> On Sun, Aug 29, 2010 at 2:39 AM, John M McIntosh <[hidden email]
> > wrote:
> I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT  
> based VM in my experimental folder.
>
> http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip
>
> I spent the last two days becoming very familiar with Open/GL and  
> rewrote the display logic to use
> Open/GL.  I am still doing some further optimization, but people  
> should test this version and let
> me know what they find.

>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Ok, so I have Ken Brown  & Mariano Martinez Peck saying  the cntl-
> arrow keys work, and Tudor Girba saying they don't work.
> Obviously I need someone to document the behaviour in a 4.x VM and  
> then in 5.8b4 so we understand what happens or doesn't happen.
>
>
> On 2010-08-29, at 7:45 AM, Ken G. Brown wrote:
>
>> ...
>> When Squeak has focus, cntl-arrow keys change Spaces as is normal  
>> on MacPro 10.6.4
>>
>> Ken G. Brown
>>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On 2010-08-29, at 10:37 AM, Tudor Girba wrote:
>
>> On 4.2.2beta1 these keys work as expected.
>>
>> I have to mention that I am still on Mac OS X 10.5.8. Perhaps the  
>> others are on Snow Leopard. Could that be a difference?
>>
>> Cheers,
>> Doru
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>

> Hi,
>
> On 29 Aug 2010, at 19:44, John M McIntosh wrote:
>
>> Ah, yes this is a functional change between 10.5 and 10.6
>>
>> Can you document a test case for me in a 4.x squeak VM so I can figure out what to do for the 10.5 users
>
> How exactly should I do that?
>
> I just checked in a 4.2.2 and everything works as expected.
>
> Cheers,
> Doru

> Ok, well I have no idea what you are using control-arrow-left key for.
> if you bring up a browser window, place the cursor in the text entry  
> input field then?
> What do you expect to happen when you tap certain keys?
>
> On 2010-08-29, at 10:50 AM, Tudor Girba wrote:
>
>> Hi,
>>
>> On 29 Aug 2010, at 19:44, John M McIntosh wrote:
>>
>>> Ah, yes this is a functional change between 10.5 and 10.6
>>>
>>> Can you document a test case for me in a 4.x squeak VM so I can  
>>> figure out what to do for the 10.5 users
>>
>> How exactly should I do that?
>>
>> I just checked in a 4.2.2 and everything works as expected.
>>
>> Cheers,
>> Doru
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>

> Ahh, I see.
>
> I expect it to jump between words. On regular Mac applications, you get this behavior by pressing alt-arrow.
>
> And when I press shift-ctrl-arrow, I expect it to select up to the end of the word. On regular Mac applications, you get this behavior by pressing alt-shift-arrow.
>
> Of course, I would not mind if instead of ctrl we would have alt :).
>
> Cheers,
> Doru
>

> Ok, you are mixing two issues here
>
> (a) I need to make the 5.8 behaviour the same as the 4.2.x VM  
> behaviour.
>
> (b) Once we have the same behaviour then you are welcome to propose  
> changing the smalltalk text editor code to make the cursor and word
> selection dance however you or the community would like it to...
>
>
> On 2010-08-29, at 11:55 AM, Tudor Girba wrote:
>
>> Ahh, I see.
>>
>> I expect it to jump between words. On regular Mac applications, you  
>> get this behavior by pressing alt-arrow.
>>
>> And when I press shift-ctrl-arrow, I expect it to select up to the  
>> end of the word. On regular Mac applications, you get this behavior  
>> by pressing alt-shift-arrow.
>>
>> Of course, I would not mind if instead of ctrl we would have alt :).
>>
>> Cheers,
>> Doru
>>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>

>
> On 2010-08-29, at 11:10 AM, stephane ducasse wrote:
>
>> John
>>
>> What I want to understand is what does it means to use open/GL.
>> This means that you use open/GL to implement the primitive?
>> Now I thought that opengl was more vector graphics than bitblt so  
>> how does it fit together.
>> Is it because the mac UI is opengl based too?
>>
>> Stef
>
> Ok let me give you some background, then talk about open/GL
>
> The Squeak drawing logic invokes:
> http://isqueak.org/displayioShowDisplay
>
> Which is to say copy this rectangle of data from the Squeak Display  
> Oops data pointer to something that visually shows the user what is  
> going on,
> since drawing can require a few Smalltalk based calculations  
> resulting in draw events to compose a final image then we also have,
>
> http://isqueak.org/ioForceDisplayUpdate
>
> To help the process a bit by allowing the drawing subsystem to  
> compose the bits until we are done, then perform the expensive step  
> of visualization.
>
> In general the displayioShowDisplay is really fast but the  
> ioForceDisplayUpdate is slow, displayioShowDisplay may not show the  
> bits, but displayioShowDisplay may now (or later... )
>
> Depending on which VM source code (version and platform dependent)  
> you may find that ioForceDisplayUpdate does nothing, or a operating  
> system flush is
> done to the hardware on every displayioShowDisplay.
>
> Where you can see this issue is if you try.
>
> Transcript cr;show:
> [| b |
> b _ Pen new.
> Display fillWhite.
> b place:(Display boundingBox bottomLeft).
> b hilbert: 9 side: 2
> ] timeToRun.
> Display restore.
>
> If this crawls, like taking 30 seconds, then the implementation is  
> flushing every bit draw to the operating system.
> Well or if you don't see the bits then maybe neither  
> displayioShowDisplay or ioForceDisplayUpdate does any flushing, and  
> all you see is the Display restore results.
>
> Now just to make life harder for the VM implementor the Smaltalk  
> code might not call ioForceDisplayUpdate.  Then the VM has to do the  
> ioForceDisplayUpdate
> internally in order not to leave bit's dangling.  How this is done  
> again is different from VM to VM.  Usually this shows up as a double  
> menu selection highlight.
>
> For the 4.2.x series of Macintosh VM we would trigger a operating  
> system flush if more than 20 ms (a settable value) had elapsed, and  
> I did nothing for ioForceDisplayUpdate.
>
> But I change this in 5.x and for the iPhone to make  
> ioForceDisplayUpdate the trigger, with a timer that pops if a  
> ioForceDisplayUpdate is not done within 20ms of the last executed  
> displayioShowDisplay.
>
> Now about Open/GL, in the past for os-x carbon VM 4.2.X and earlier  
> we used System 7.5.x technology to draw bits, which was quickdraw  
> and quickdraw quartz.
>
> When I moved the logic to the iPhone that is not supported  
> technology, because of the interesting drawing logic on the iPhone  
> it took 6 attempts and a long
> chat with a graphics engineer at Apple. That resulted in using Core  
> Animation to divide the screen into 16 tiles so when a draw happens  
> we note which Tile(s) are dirty
> based on the rectangle intersections, then on the  
> ioForceDisplayUpdate we generate images for each of the dirty tiles  
> from the Display Oops and tell Core Animation
> redraw the new tiles.
>
> Bert said this seemed slow on OS-X.
>
> At this point the next step in our OS-X/iOS drawing path is drop one  
> step lower down and consider Open/GL.
>
> I must admit I've not done any open/GL work before so it was a  
> learning opportunity.
>
> Although you think of Open/GL as a vector based graphic language it  
> does support what is know as Textures.
>
> So instead of providing vectors, you supply bits. So a chunk of  
> data, stating it's RGB, at this depth and pixel layout and size, etc  
> make a chunk of screen glow that is showing the open/GL viewport.
>
> Now there are lots of restrictions but the GPUs and drivers have  
> become more friendly so you can supply arbitrary sized rectangles,  
> this was at one time slow, but GPUs have become extremely fast, so  
> slow is fast...
>
> In fact on the mac you can supply a arbitrary sized rectangle taken  
> from a much larger rectangle of data, which fits perfectly into the  
> displayioShowDisplay logic.
>
> The only hassle is that you need to figure out how the flush should  
> work.  So after 3 days of intense effort I can say the algorithm is...
>
>
> displayioShowDisplay
>
> collects the union of the rectangles that are being drawn.  Nothing  
> more happens... It's pointless to do the glTexImage2D here because  
> 'b hilbert: 9 side: 2' will kill you.
> Mind we do still watch for a missing ioForceDisplayUpdate.
>
> ioForceDisplayUpdate
>
> Then takes the union of the rectangles, set a GL viewpoint, and  
> does the glTexImage2D based on figuring out the start point of the  
> top/left pixel of the rectangle to draw,
> then setups up the coordinate system and finally flush the data.
>
> glViewport( subRect.origin.x,subRect.origin.y,  
> subRect.size.width,subRect.size.height );
>
> char *subimg = ((char*)lastBitsIndex) + (unsigned int)
> (subRect.origin.x + (r.size.height-subRect.origin.y-
> subRect.size.height)*r.size.width)*4;
> glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA,  
> subRect.size.width, subRect.size.height, 0, GL_BGRA,  
> GL_UNSIGNED_INT_8_8_8_8_REV, subimg );
>
> glBegin(GL_QUADS);   // The -1 is so we flip the coordinate system  
> as os-x and squeak have different views of where (0,0) is...
> glTexCoord2f(0.0f, 0.0f);
> glVertex2f(-1.0f, 1.0f);
> glTexCoord2f(0.0f, subRect.origin.x.size.height);
> glVertex2f(-1.0f, -1.0f);
> glTexCoord2f(subRect.origin.x.size.width,  
> subRect.origin.x.size.height);
> glVertex2f(1.0f, -1.0f);
> glTexCoord2f(subRect.origin.x.size.width, 0.0f);
> glVertex2f(1.0f, 1.0f);
> glEnd();
>
> glFlush() // Ask the hardware to draw this stuff, don't use the  
> more aggressive glFinish()
> reset the union of draw rectangles.
>
> Hint
> (a) Oddly some people feel they should re-configure the open/GL  
> graphic context on *every* draw cycle, why?
> (b) People don't read the Apple guidebooks for best practices for  
> doing glTexImage2D, this I know based on Google searches using  
> certain Apple open/GL extension keywords.
>
> Notes:
>
> This assumes the Squeak display is 32 bits, other resolutions are an  
> exercise for the reader.
> Actually if the row width is a multiple of 32 bytes then on the Mac  
> things are *much* faster and no copy is made.  This is enforced in  
> 5.7b5 by ensuring window size is divisible by 8.
>
> When the graphic context is setup when the window is built there is  
> a bunch of cmds to execute, one important one is
> glPixelStorei( GL_UNPACK_ROW_LENGTH, self.frame.size.width );
> and when the window is resized there are a few things to do to  
> indicate how the context has changed.
>
> Some platforms like the iPhone might need to do this instead because  
> it doesn't support the GL extension GL_TEXTURE_RECTANGLE_ARB
>
> glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, subRect.size.width,  
> subRect.size.height, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL );
>
> for( int y = 0; y < subRect.size.height; y++ )
> {
> char *row =  ((char*)lastBitsIndex)  + ((y +  
> subRect.origin.y)*subRect.size.width + subRect.origin.x) * 4;
> glTexSubImage2D( GL_TEXTURE_2D, 0, 0, y, subRect.size.width, 1,  
> GL_RGBA, GL_UNSIGNED_BYTE, row );
> }
>
>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
>
>> Hi,
>>
>> Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
>>
>> I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
>>
>> Cheers,
>> Doru
>
> --
> ===========================================================================
> John M. McIntosh<[hidden email]>    Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>
>
>

>>
>> Cheers,
>> Doru
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
> <smime.p7s><ATT00001..txt>

> On 9/2/2010 11:30 AM, John M McIntosh wrote:
>> I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
>>
>> Oh like http://www.squeaksource.com/AlienOpenGL
>
> Or http://www.squeaksource.com/CroquetGL (much more complete w/
> extensions etc). Something like this might just work:
>
> (OpenGL new)
> glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0;
> swapBuffers.
>
> Cheers,
>   - Andreas
>
>>
>> On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
>>>
>>> I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
>>>
>>> Cheers,
>>> Doru
>>
>> --
>> ===========================================================================
>> John M. McIntosh<[hidden email]>    Twitter:  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> ===========================================================================
>>
>>
>>
>>
>>
>>
>>
>>
>
>

> Ahh! And also what Andreas mentions.
>
>   AlienOpenGL is not current being maintained and is missing features.
> Although it works for what i needed it at the moment.
>
> Tudor: if you are going to the ESUG we could spend some time with this.
>
> Saludos,
> Fernando
>
>
>
>
> On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
>
>> On 9/2/2010 11:30 AM, John M McIntosh wrote:
>>> I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
>>>
>>> Oh like http://www.squeaksource.com/AlienOpenGL
>> Or http://www.squeaksource.com/CroquetGL (much more complete w/
>> extensions etc). Something like this might just work:
>>
>> (OpenGL new)
>> glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0;
>> swapBuffers.
>>
>> Cheers,
>>    - Andreas
>>
>>> On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
>>>>
>>>> I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
>>>>
>>>> Cheers,
>>>> Doru
>>> --
>>> ===========================================================================
>>> John M. McIntosh<[hidden email]>     Twitter:  squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> ===========================================================================
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project