Hi,
i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images. I'd like you to ask to test and load it and tell me if it works for you. Currently it works only on win32 platform. It could work on Linux, but i didn't had time to port it yet. There is no automatic installation procedure right now, so here what you should try: - first, you need to have VM with NativeBoost plugin + NativeBoost loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL in following order: - NBOpenGL-Core - NBOpenGL-Win - NBOpenGL-TrueType - NBOpenGL-Display - NBOpenGL-Morphic i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems. Now, if everything went right, then we're ready to run a demo: GLViewportMorph new "useOwnForm: true;" openInWorld This thing should render a TrueType glyphs and animating a smooth zoom of it. Nothing fancy, i just wanna know, if it works for you (and how well). :) As you may know, GPU/OpenGL implementations vary depending on vendor and how old your hardware is, and i don't have all of it at my disposal. Ok.. if you got it running, and it renders the glyphs.. there's one thing left: - save your image and quit (without closing this morph) - start image it should continue working as if nothing happens. -- Best regards, Igor Stasenko AKA sig. |
On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko <[hidden email]>
wrote: > Hi, > > i just snapshotted my stuff with various fixes, to make it load > cleanly on pharo and squeak images. > > I'd like you to ask to test and load it and tell me if it works for you. Beautiful! Works exactly as you describe; I'm on an older Windows XP system, 2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB. The animation loop's running fast and smooth, and doesn't seem to be giving much cpu load. I'm using a fresh trunk image, running the VM listed in your install instructions. The second line of text starts with some cyrillic-looking characters; but in the Squeak system browser for GLViewportMorph>>drawOn: the string shows with question marks; so I guess that thing you're doing with the truetype code block might be working. > it should continue working as if nothing happens. Yep. Very cool! Kevin Kelley |
On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote:
> On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko <[hidden email]> > wrote: > >> Hi, >> >> i just snapshotted my stuff with various fixes, to make it load >> cleanly on pharo and squeak images. >> >> I'd like you to ask to test and load it and tell me if it works for you. > > Beautiful! Works exactly as you describe; I'm on an older Windows XP > system, > 2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB. The animation > loop's > running fast and smooth, and doesn't seem to be giving much cpu load. > Well, actually it does :) I implemented it specifically to be embedded into a squeak's Display, so i could run it and see what happens, without any distortion/visual artifacts and keep working while it runs. First, it renders everything into offscreen surface, and then it reads results from video memory into a display form, and then DisplayScreen + VM takes care about blitting that form back to video memory (or anywhere else it wants). In case if we will replace all drawing by using GL, then we won't need to blit bits back to system memory, and then all processing will be completely performed by GPU. It will be much faster. You can see how much slowdown is introduced by blitting, if you resize the morph to cover full screen. > I'm using a fresh trunk image, running the VM listed in your install > instructions. > > The second line of text starts with some cyrillic-looking characters; but in > the Squeak system browser for GLViewportMorph>>drawOn: the string shows with > question marks; so I guess that thing you're doing with the truetype code > block > might be working. > Yes, it works as i described (in other thread). I subclassed TTFontReader to support reading character maps with pId=3, allowing you to use all glyphs of windoze fonts. >> it should continue working as if nothing happens. > > Yep. Very cool! > > Kevin Kelley > > -- Best regards, Igor Stasenko AKA sig. |
Btw, i noticed that running it full-screen in pharo is still quite
fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there. In both images, i used: Display depth 32 Display isLittleEndian true -- Best regards, Igor Stasenko AKA sig. |
On Mon, 24 May 2010, Igor Stasenko wrote:
> Btw, i noticed that running it full-screen in pharo is still quite > fast and smooth, > which makes me wonder, what extra a squeak image does to perform > blitting on screen. > Something slows things down there. Did you try the profiler (Extras menu)? I found it pretty useful when I was hacking RFB recently. Levente > > In both images, i used: > > Display depth 32 > Display isLittleEndian true > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
On 24 May 2010 23:06, Levente Uzonyi <[hidden email]> wrote:
> On Mon, 24 May 2010, Igor Stasenko wrote: > >> Btw, i noticed that running it full-screen in pharo is still quite >> fast and smooth, >> which makes me wonder, what extra a squeak image does to perform >> blitting on screen. >> Something slows things down there. > > Did you try the profiler (Extras menu)? I found it pretty useful when I was > hacking RFB recently. > The tally looks weird :) - 100146 tallies, 100419 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 5.7% {5724ms} EventSensor>>eventTickler 5.7% {5724ms} Delay>>wait 5.7% {5724ms} primitives -------------------------------- Process: (40) 43725: nil -------------------------------- 94.3% {94695ms} WorldState>>doOneCycleFor: 94.3% {94695ms} WorldState>>doOneCycleNowFor: 93.9% {94293ms} WorldState>>displayWorldSafely: 93.9% {94293ms} PasteUpMorph>>displayWorld 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld 93.9% {94293ms} WorldState>>displayWorld:submorphs: 85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn: |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: | 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder | |39.6% {39766ms} primitives | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: | | 34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn: | | 33.9% {34042ms} FormCanvas(Canvas)>>drawMorph: | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: | | 33.9% {34042ms} GLViewportMorph>>drawOn: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: | 10.9% {10946ms} FormCanvas(Canvas)>>draw: | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: | 10.9% {10946ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | 10.8% {10845ms} FormCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} FormCanvas>>balloonFillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: | 10.7% {10745ms} BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: | 10.7% {10745ms} BalloonEngine>>postFlushIfNeeded | 10.7% {10745ms} BalloonEngine>>copyBits | 10.7% {10745ms} BalloonEngine>>copyLoopFaster | 10.7% {10745ms} primitives 8.3% {8335ms} WorldState>>forceDamageToScreen: 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: 8.3% {8335ms} OrderedCollection>>do: **Leaves** 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer 10.7% {10745ms} BalloonEngine>>copyLoopFaster 8.3% {8335ms} OrderedCollection>>do: 5.7% {5724ms} Delay>>wait **Memory** old +193,508 bytes young +173,384 bytes used +366,892 bytes free -366,892 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms tenures 2 (avg 665 GCs/tenure) root table 0 overflows -------- This is weird it shows that it spends 40% of time in SystemWindow(Morph)>>hasRolloverBorder The actual workload should be concentrated here: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer but it takes only 1/3 of all time (this is including blitting bits back to system memory). What is interesting, that if there is no copy to system memory, rendering these simple things (about 60 glyphs with nice AA), takes less than 2% of time: | 1.6% {689ms} GLViewportMorph>>drawOn: while most of the time, again spent in #hasRolloverBorder **Leaves** 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder 15.9% {6848ms} BalloonEngine>>copyLoopFaster 12.0% {5169ms} OrderedCollection>>do: 4.7% {2024ms} Delay>>wait So, it could run 32%/2% ~~ 16 times faster > > Levente > >> >> In both images, i used: >> >> Display depth 32 >> Display isLittleEndian true >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
On 5/24/2010 1:28 PM, Igor Stasenko wrote:
> On 24 May 2010 23:06, Levente Uzonyi<[hidden email]> wrote: >> On Mon, 24 May 2010, Igor Stasenko wrote: >> >>> Btw, i noticed that running it full-screen in pharo is still quite >>> fast and smooth, >>> which makes me wonder, what extra a squeak image does to perform >>> blitting on screen. >>> Something slows things down there. >> >> Did you try the profiler (Extras menu)? I found it pretty useful when I was >> hacking RFB recently. >> > > The tally looks weird :) http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405.html A real-world case of issue #3. Cheers, - Andreas > - 100146 tallies, 100419 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 5.7% {5724ms} EventSensor>>eventTickler > 5.7% {5724ms} Delay>>wait > 5.7% {5724ms} primitives > -------------------------------- > Process: (40) 43725: nil > -------------------------------- > 94.3% {94695ms} WorldState>>doOneCycleFor: > 94.3% {94695ms} WorldState>>doOneCycleNowFor: > 93.9% {94293ms} WorldState>>displayWorldSafely: > 93.9% {94293ms} PasteUpMorph>>displayWorld > 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld > 93.9% {94293ms} WorldState>>displayWorld:submorphs: > 85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn: > |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: > | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: > | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: > | 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder > | |39.6% {39766ms} primitives > | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: > | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: > | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: > | | 34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn: > | | 33.9% {34042ms} FormCanvas(Canvas)>>drawMorph: > | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: > | | 33.9% {34042ms} GLViewportMorph>>drawOn: > | | 32.8% {32937ms} > NBMSAAOffscreenDisplay>>updateForm:bounds: > | | 32.7% {32837ms} > NBGLFrameBuffer>>bindAsDrawBuffer > | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: > | 10.9% {10946ms} FormCanvas(Canvas)>>draw: > | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: > | 10.9% {10946ms} > FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: > | 10.8% {10845ms} > FormCanvas>>fillRectangle:fillStyle: > | 10.8% {10845ms} > FormCanvas>>balloonFillRectangle:fillStyle: > | 10.8% {10845ms} > BalloonCanvas>>fillRectangle:fillStyle: > | 10.8% {10845ms} > BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: > | 10.7% {10745ms} > BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: > | 10.7% {10745ms} > BalloonEngine>>postFlushIfNeeded > | 10.7% {10745ms} BalloonEngine>>copyBits > | 10.7% {10745ms} > BalloonEngine>>copyLoopFaster > | 10.7% {10745ms} primitives > 8.3% {8335ms} WorldState>>forceDamageToScreen: > 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: > 8.3% {8335ms} OrderedCollection>>do: > > **Leaves** > 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder > 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer > 10.7% {10745ms} BalloonEngine>>copyLoopFaster > 8.3% {8335ms} OrderedCollection>>do: > 5.7% {5724ms} Delay>>wait > > **Memory** > old +193,508 bytes > young +173,384 bytes > used +366,892 bytes > free -366,892 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms > tenures 2 (avg 665 GCs/tenure) > root table 0 overflows > > -------- > This is weird it shows that it spends 40% of time in > SystemWindow(Morph)>>hasRolloverBorder > > The actual workload should be concentrated here: > | | 32.8% {32937ms} > NBMSAAOffscreenDisplay>>updateForm:bounds: > | | 32.7% {32837ms} > NBGLFrameBuffer>>bindAsDrawBuffer > > but it takes only 1/3 of all time (this is including blitting bits > back to system memory). > > > > What is interesting, that if there is no copy to system memory, > rendering these simple things (about > 60 glyphs with nice AA), takes less than 2% of time: > > | 1.6% {689ms} GLViewportMorph>>drawOn: > > while most of the time, again spent in #hasRolloverBorder > **Leaves** > 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder > 15.9% {6848ms} BalloonEngine>>copyLoopFaster > 12.0% {5169ms} OrderedCollection>>do: > 4.7% {2024ms} Delay>>wait > > So, it could run 32%/2% ~~ 16 times faster > > >> >> Levente >> >>> >>> In both images, i used: >>> >>> Display depth 32 >>> Display isLittleEndian true >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> > > > |
In reply to this post by Igor Stasenko
For GLViewportMorph, it takes ~ 9ms to render a frame + blit results
to system memory: | canv | canv := Display getCanvas. [ 1000 timesRepeat: [ self drawOn: canv ] ] timeToRun 9714 if i disabling blitting to system memory, then the above loop takes 789 ms < 1 ms per frame Drawing a system window morph with 600@400 extent (an outer morph , which is a little bit bigger than GLViewportMorph which sits inside of it): 4327 ~ 4ms per frame (its just fills the rectangle with constant color) For the same window on pharo it takes just 1393 ms. Scaling a system window (along with GLViewportMorph) to 1200@800 GLViewportMorph + blit to system memory - 24611 ms GLViewportMorph w/o blit to system memory - 754 ms SystemWindow - 12351 so, with increase of drawable area by 4x factor, rendering times not changes. blitting to system memory is 2.5 slower and drawing a rectangle is 4x slower - a worst result showing an exact linear dependency from covered area. -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Andreas.Raab
On 25 May 2010 00:18, Andreas Raab <[hidden email]> wrote:
> On 5/24/2010 1:28 PM, Igor Stasenko wrote: >> >> On 24 May 2010 23:06, Levente Uzonyi<[hidden email]> wrote: >>> >>> On Mon, 24 May 2010, Igor Stasenko wrote: >>> >>>> Btw, i noticed that running it full-screen in pharo is still quite >>>> fast and smooth, >>>> which makes me wonder, what extra a squeak image does to perform >>>> blitting on screen. >>>> Something slows things down there. >>> >>> Did you try the profiler (Extras menu)? I found it pretty useful when I >>> was >>> hacking RFB recently. >>> >> >> The tally looks weird :) > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405.html > > A real-world case of issue #3. > Oh, i see. So this is actually a time spent to draw a systemwindow background. Btw, i discovered that openGL driver distributes the load over all 4 cores of my pc. > Cheers, > - Andreas > >> - 100146 tallies, 100419 msec. >> >> **Tree** >> -------------------------------- >> Process: other processes >> -------------------------------- >> 5.7% {5724ms} EventSensor>>eventTickler >> 5.7% {5724ms} Delay>>wait >> 5.7% {5724ms} primitives >> -------------------------------- >> Process: (40) 43725: nil >> -------------------------------- >> 94.3% {94695ms} WorldState>>doOneCycleFor: >> 94.3% {94695ms} WorldState>>doOneCycleNowFor: >> 93.9% {94293ms} WorldState>>displayWorldSafely: >> 93.9% {94293ms} PasteUpMorph>>displayWorld >> 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld >> 93.9% {94293ms} WorldState>>displayWorld:submorphs: >> 85.6% {85959ms} >> WorldState>>drawWorld:submorphs:invalidAreasOn: >> |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: >> | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: >> | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: >> | 39.6% {39766ms} >> SystemWindow(Morph)>>hasRolloverBorder >> | |39.6% {39766ms} primitives >> | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: >> | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: >> | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: >> | | 34.1% {34243ms} >> GLViewportMorph(Morph)>>fullDrawOn: >> | | 33.9% {34042ms} >> FormCanvas(Canvas)>>drawMorph: >> | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: >> | | 33.9% {34042ms} GLViewportMorph>>drawOn: >> | | 32.8% {32937ms} >> NBMSAAOffscreenDisplay>>updateForm:bounds: >> | | 32.7% {32837ms} >> NBGLFrameBuffer>>bindAsDrawBuffer >> | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: >> | 10.9% {10946ms} FormCanvas(Canvas)>>draw: >> | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: >> | 10.9% {10946ms} >> FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: >> | 10.8% {10845ms} >> FormCanvas>>fillRectangle:fillStyle: >> | 10.8% {10845ms} >> FormCanvas>>balloonFillRectangle:fillStyle: >> | 10.8% {10845ms} >> BalloonCanvas>>fillRectangle:fillStyle: >> | 10.8% {10845ms} >> BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: >> | 10.7% {10745ms} >> BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: >> | 10.7% {10745ms} >> BalloonEngine>>postFlushIfNeeded >> | 10.7% {10745ms} >> BalloonEngine>>copyBits >> | 10.7% {10745ms} >> BalloonEngine>>copyLoopFaster >> | 10.7% {10745ms} primitives >> 8.3% {8335ms} WorldState>>forceDamageToScreen: >> 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: >> 8.3% {8335ms} OrderedCollection>>do: >> **Leaves** >> 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder >> 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer >> 10.7% {10745ms} BalloonEngine>>copyLoopFaster >> 8.3% {8335ms} OrderedCollection>>do: >> 5.7% {5724ms} Delay>>wait >> >> **Memory** >> old +193,508 bytes >> young +173,384 bytes >> used +366,892 bytes >> free -366,892 bytes >> >> **GCs** >> full 0 totalling 0ms (0.0% uptime) >> incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms >> tenures 2 (avg 665 GCs/tenure) >> root table 0 overflows >> >> -------- >> This is weird it shows that it spends 40% of time in >> SystemWindow(Morph)>>hasRolloverBorder >> >> The actual workload should be concentrated here: >> | | 32.8% {32937ms} >> NBMSAAOffscreenDisplay>>updateForm:bounds: >> | | 32.7% {32837ms} >> NBGLFrameBuffer>>bindAsDrawBuffer >> >> but it takes only 1/3 of all time (this is including blitting bits >> back to system memory). >> >> >> >> What is interesting, that if there is no copy to system memory, >> rendering these simple things (about >> 60 glyphs with nice AA), takes less than 2% of time: >> >> | 1.6% {689ms} GLViewportMorph>>drawOn: >> >> while most of the time, again spent in #hasRolloverBorder >> **Leaves** >> 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder >> 15.9% {6848ms} BalloonEngine>>copyLoopFaster >> 12.0% {5169ms} OrderedCollection>>do: >> 4.7% {2024ms} Delay>>wait >> >> So, it could run 32%/2% ~~ 16 times faster >> >> >>> >>> Levente >>> >>>> >>>> In both images, i used: >>>> >>>> Display depth 32 >>>> Display isLittleEndian true >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >>> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Igor Stasenko
On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko <[hidden email]>
wrote: > On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote: >> >>> The animation loop's >> running fast and smooth, and doesn't seem to be giving much cpu load. >> > > Well, actually it does :) Okay, so the memcopy's are taking up a little bit of time; still, the big win so far is having the gpu render the font glyph based on just the outline data, you're getting scalable fonts on the fly effectively for free. This is seriously cool. That GPU gems link ( http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html ) referenced in your code is a good explanation. Shaders kind of break my brain, I'm glad to see this one in and working. Cheers, Kevin Kelley |
On 25 May 2010 02:13, Kevin Kelley <[hidden email]> wrote:
> On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko <[hidden email]> > wrote: >> >> On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote: >>> >>>> The animation loop's >>> >>> running fast and smooth, and doesn't seem to be giving much cpu load. >>> >> >> Well, actually it does :) > > Okay, so the memcopy's are taking up a little bit of time; still, the big > win > so far is having the gpu render the font glyph based on just the outline > data, > you're getting scalable fonts on the fly effectively for free. This is > seriously > cool. > > That GPU gems link ( > http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html ) > referenced in your code is a good explanation. Shaders kind of break my > brain, > I'm glad to see this one in and working. > the rest is just a piece of cake. Btw, this is my first shader routine i ever written :) > Cheers, > Kevin Kelley > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Igor Stasenko
On 5/24/2010 7:03 AM, Igor Stasenko wrote:
> - first, you need to have VM with NativeBoost plugin + NativeBoost > loaded into an image > (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) The page doesn't have any information on how to download the binary plugin. Do I really need to rebuild it from sources? > - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL > in following order: > > - NBOpenGL-Core > - NBOpenGL-Win This fails with the following error: -------------------------------------------------------------- This package depends on the following classes: NBWinTypes NBWinConstants You must resolve these dependencies before you will be able to load these definitions: GLPixelFormatDescriptor .... -------------------------------------------------------------- > i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were > released recently, and it seems works ok. > on squeak/trunk it should also work without problems. I've used 4.1 but I don't think this should matter for the above, no? > Now, if everything went right, then we're ready to run a demo: > > GLViewportMorph new "useOwnForm: true;" openInWorld And ultimately this fails too due to GLPixelFormatDescriptor not loaded. Any ideas what's wrong with NBWinTypes and NBWinConstants? Cheers, - Andreas |
On 25 May 2010 03:47, Andreas Raab <[hidden email]> wrote:
> On 5/24/2010 7:03 AM, Igor Stasenko wrote: >> >> - first, you need to have VM with NativeBoost plugin + NativeBoost >> loaded into an image >> (see http://code.google.com/p/nativeboost/wiki/Installation for >> instructions) > > The page doesn't have any information on how to download the binary plugin. > Do I really need to rebuild it from sources? > You can just take a prebuilt VM from http://code.google.com/p/nativeboost/downloads/list >> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL >> in following order: >> >> - NBOpenGL-Core >> - NBOpenGL-Win > > This fails with the following error: > > -------------------------------------------------------------- > > This package depends on the following classes: > NBWinTypes > NBWinConstants > You must resolve these dependencies before you will be able to load these > definitions: > GLPixelFormatDescriptor > .... > -------------------------------------------------------------- > >> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were >> released recently, and it seems works ok. >> on squeak/trunk it should also work without problems. > > I've used 4.1 but I don't think this should matter for the above, no? > >> Now, if everything went right, then we're ready to run a demo: >> >> GLViewportMorph new "useOwnForm: true;" openInWorld > > And ultimately this fails too due to GLPixelFormatDescriptor not loaded. > > Any ideas what's wrong with NBWinTypes and NBWinConstants? > You need to install a NativeBoost first. NBOpenGL is separate thing which using a NativeBoost. > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
On 5/24/2010 6:17 PM, Igor Stasenko wrote:
> You can just take a prebuilt VM from > http://code.google.com/p/nativeboost/downloads/list Okay, good, that's what I did. FWIW, there's an installation bug for NB. When you run "NBInstaller install" *without* the plugin, it will fail to determine the platform id and will not install the Windows stuff. That's what caused my later problems. I would recommend installing *all* platform examples regardless of actual platform id to avoid issues like these. I find Unix examples just as instructive as Windows examples ;-) However, even after doing that, it fails to run. It blows up in NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf: sym" to resolve the code. When I fix that it gets me to an GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now. In case it helps, the offending code is in NBMSAAOffscreenDisplay>>initDisplay "perform a usual initializations" renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent. renderFBO createMultisampleAttachments: 4. renderFBO checkStatus. "... more stuff ..." Any ideas what to look for? I have an ATI Mobility Radeon HD 4330 running Windows 7. Cheers, - Andreas |
On 25 May 2010 05:57, Andreas Raab <[hidden email]> wrote:
> On 5/24/2010 6:17 PM, Igor Stasenko wrote: >> >> You can just take a prebuilt VM from >> http://code.google.com/p/nativeboost/downloads/list > > Okay, good, that's what I did. FWIW, there's an installation bug for NB. > When you run "NBInstaller install" *without* the plugin, it will fail to > determine the platform id and will not install the Windows stuff. That's > what caused my later problems. I would recommend installing *all* platform > examples regardless of actual platform id to avoid issues like these. I find > Unix examples just as instructive as Windows examples ;-) > > However, even after doing that, it fails to run. It blows up in > NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf: sym" > to resolve the code. Thanks for finding it! I never run into that code, that's why it wasn't tested. :) > When I fix that it gets me to an > GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now. In > case it helps, the offending code is in > > NBMSAAOffscreenDisplay>>initDisplay > "perform a usual initializations" > renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent. > renderFBO createMultisampleAttachments: 4. > renderFBO checkStatus. > "... more stuff ..." > > Any ideas what to look for? I have an ATI Mobility Radeon HD 4330 running > Windows 7. > It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided. Check that NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil i suspect this is your problem, because you're unlucky owner of wrong hardware/drivers :) http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=234085 Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay " > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
> It either your card doesn't supports MSAA, > or driver don't likes the FBO configuration which i provided. I think the error code indicates a problem with the FBO configuration. For example, check out the restrictions on OpenGL ES for this stuff: http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml It seems as if one needs to be very picky for getting the 'right' configuration on all platforms. Is there an enumeration by any chance that allows one to pick the proper (supported) configuration? > Check that > > NBWinContextState new pixelFormatInfo extensions includes: > #GL_EXT_packed_depth_stencil It's there. > Also, you could try running with MSAA turned off, go to > NBGLDisplay class>>pickImplementation > and put comment around " ^ NBMSAAOffscreenDisplay " That appears to work but the glyphs are drawn "improperly" (see screenshot). I'm not sure if that's the way they're intended to be rendered or if that's an artifact of running a different configuration. Cheers, - Andreas NBRender.jpg (65K) Download Attachment |
On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote:
> On 5/24/2010 8:32 PM, Igor Stasenko wrote: >> >> It either your card doesn't supports MSAA, >> or driver don't likes the FBO configuration which i provided. > > I think the error code indicates a problem with the FBO configuration. For > example, check out the restrictions on OpenGL ES for this stuff: > > http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml > > It seems as if one needs to be very picky for getting the 'right' > configuration on all platforms. Is there an enumeration by any chance that > allows one to pick the proper (supported) configuration? > (that's all what i need). You may try various things in NBGLFrameBuffer>>createMultisampleAttachments: numSamples or in NBGLFrameBuffer>>createAttachments >> Check that >> >> NBWinContextState new pixelFormatInfo extensions includes: >> #GL_EXT_packed_depth_stencil > > It's there. > >> Also, you could try running with MSAA turned off, go to >> NBGLDisplay class>>pickImplementation >> and put comment around " ^ NBMSAAOffscreenDisplay " > > That appears to work but the glyphs are drawn "improperly" (see screenshot). > I'm not sure if that's the way they're intended to be rendered or if that's > an artifact of running a different configuration. > buffer (or have it disabled). Your screenshot also shows that you got my little shader running properly which is used to render quad beziers. And this is more important than stencil (i think it could be solved by picking different FBO attachment formats). > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. GL viewport.png (39K) Download Attachment |
It works fine for me (Geforce 8800GTS).
Maybe Andreas needs updated drivers? That's helped some people with similar problems: http://www.gamedev.net/community/forums/topic.asp?topic_id=568410 Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions: http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093&enterthread=y Cheers, Josh On May 24, 2010, at 9:48 PM, Igor Stasenko wrote: > On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote: >> On 5/24/2010 8:32 PM, Igor Stasenko wrote: >>> >>> It either your card doesn't supports MSAA, >>> or driver don't likes the FBO configuration which i provided. >> >> I think the error code indicates a problem with the FBO configuration. For >> example, check out the restrictions on OpenGL ES for this stuff: >> >> http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml >> >> It seems as if one needs to be very picky for getting the 'right' >> configuration on all platforms. Is there an enumeration by any chance that >> allows one to pick the proper (supported) configuration? >> > Yeah.. this is a black voodoo. > For instance, my video card rejects FBO with color+stencil only > (that's all what i need). > You may try various things in > NBGLFrameBuffer>>createMultisampleAttachments: numSamples > or in NBGLFrameBuffer>>createAttachments > >>> Check that >>> >>> NBWinContextState new pixelFormatInfo extensions includes: >>> #GL_EXT_packed_depth_stencil >> >> It's there. >> >>> Also, you could try running with MSAA turned off, go to >>> NBGLDisplay class>>pickImplementation >>> and put comment around " ^ NBMSAAOffscreenDisplay " >> >> That appears to work but the glyphs are drawn "improperly" (see screenshot). >> I'm not sure if that's the way they're intended to be rendered or if that's >> an artifact of running a different configuration. >> > > Yes, its improper. It looks like that when you don't have a stencil > buffer (or have it disabled). > Your screenshot also shows that you got my little shader running > properly which is used to render quad beziers. > And this is more important than stencil (i think it could be solved by > picking different FBO attachment formats). > > >> Cheers, >> - Andreas >> > > > -- > Best regards, > Igor Stasenko AKA sig. > <GL viewport.png> |
On 29 May 2010 09:41, Josh Gargus <[hidden email]> wrote:
> It works fine for me (Geforce 8800GTS). > > Maybe Andreas needs updated drivers? That's helped some people with similar problems: > http://www.gamedev.net/community/forums/topic.asp?topic_id=568410 > > Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions: > http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093&enterthread=y > Yes, its a long-standing problem with ATI drivers (i hope not with cards). Henrik also reported that it unable to create MSAA FBO on his Radeopn HD4870. I wonder if ATI cards/drivers ever support depth+stencil multisampling in FBOs. Actually, i could use back buffer for rendering instead of FBO. > Cheers, > Josh > > > > On May 24, 2010, at 9:48 PM, Igor Stasenko wrote: > >> On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote: >>> On 5/24/2010 8:32 PM, Igor Stasenko wrote: >>>> >>>> It either your card doesn't supports MSAA, >>>> or driver don't likes the FBO configuration which i provided. >>> >>> I think the error code indicates a problem with the FBO configuration. For >>> example, check out the restrictions on OpenGL ES for this stuff: >>> >>> http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml >>> >>> It seems as if one needs to be very picky for getting the 'right' >>> configuration on all platforms. Is there an enumeration by any chance that >>> allows one to pick the proper (supported) configuration? >>> >> Yeah.. this is a black voodoo. >> For instance, my video card rejects FBO with color+stencil only >> (that's all what i need). >> You may try various things in >> NBGLFrameBuffer>>createMultisampleAttachments: numSamples >> or in NBGLFrameBuffer>>createAttachments >> >>>> Check that >>>> >>>> NBWinContextState new pixelFormatInfo extensions includes: >>>> #GL_EXT_packed_depth_stencil >>> >>> It's there. >>> >>>> Also, you could try running with MSAA turned off, go to >>>> NBGLDisplay class>>pickImplementation >>>> and put comment around " ^ NBMSAAOffscreenDisplay " >>> >>> That appears to work but the glyphs are drawn "improperly" (see screenshot). >>> I'm not sure if that's the way they're intended to be rendered or if that's >>> an artifact of running a different configuration. >>> >> >> Yes, its improper. It looks like that when you don't have a stencil >> buffer (or have it disabled). >> Your screenshot also shows that you got my little shader running >> properly which is used to render quad beziers. >> And this is more important than stencil (i think it could be solved by >> picking different FBO attachment formats). >> >> >>> Cheers, >>> - Andreas >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <GL viewport.png> > > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |