Re: [Tuxpaint-dev] Tinting in CVS
On Fri, Nov 26, 2004 at 07:21:17PM -0500, Albert Cahalan wrote: > First of all, the butterfly is looking better than ever > for me. It tints perfectly. I'll send you an example. *blush* I was NOT using the latest tuxpaint-stamps from CVS, sorry. :^( I had updated everything on my wife's laptop, but not on my desktop. What a goof. I have an excuse, though... I've been under the weather lately. :^P > I'd have expected your PC to be very fast at this, because > the PC has built-in trancedental math functions in the CPU. > You have instructions for sin(), cos(), tan(), and so on. > > Unlikely to be the problem, but... > > One thing that may need to change for a PC is the place where > a double is compared against zero. Instead of this: > > if(dst.sat>0) > > You might be better off with: > > if(dst.sat>0.0001) I can give it a try. Thanks -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 2004-11-26 at 21:23, Mark K. Kim wrote: > On Fri, 26 Nov 2004, Albert Cahalan wrote: > > > One thing that may need to change for a PC is the place where > > a double is compared against zero. Instead of this: > > > > if(dst.sat>0) > > > > You might be better off with: > > > > if(dst.sat>0.0001) > > How does that offer performance increase??? Generally, it doesn't. It's a matter of accuracy in being able to determine if the destination color is greyscale. This is just a possible bug that popped into my head while thinking about the code, nothing more. (a Mac handles this well, but a PC has a variable number of fraction bits because of the truncation that occurs when an 80-bit float is spilled to a 64-bit stack location) There could be a place where something like the above would send the code around for a loop though. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 26 Nov 2004, Albert Cahalan wrote: > Windows profiler output might be helpful too. Surely there > are some suitable tools... maybe Intel provides some? I think Visual C/C++ comes with a profiler. Haven't we been able to compile Tux Paint using both MinGW and VC? If that's the case, we could use VC's profiler, if someone with VC could volunteer! -Mark (*not* a VC user) -- Mark K. Kim AIM: markus kimius Homepage: http://www.cbreak.org/ Xanga: http://www.xanga.com/vindaci Friendster: http://www.friendster.com/user.php?uid=13046 PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE PGP key available on the homepage ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 26 Nov 2004, Albert Cahalan wrote: > One thing that may need to change for a PC is the place where > a double is compared against zero. Instead of this: > > if(dst.sat>0) > > You might be better off with: > > if(dst.sat>0.0001) How does that offer performance increase??? -Mark -- Mark K. Kim AIM: markus kimius Homepage: http://www.cbreak.org/ Xanga: http://www.xanga.com/vindaci Friendster: http://www.friendster.com/user.php?uid=13046 PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE PGP key available on the homepage ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
This may have something to do with the performance: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3) This compiler does alias analysis and whole-file optimization. If that does the job for you, then don't worry. Most users will be getting binaries compiled with gcc 3.4 or later. For the Windows build, ensure that the fast math options are enabled. (using the x86 transcedental math instructions) If alias analysis is an option, enable that too. There are plenty of opportunities for hand-optimizing the code if compiler adjustments don't do the job. I didn't bother, because a bone-headed implementation was easier to develop and plenty fast on my system. Some ideas are: a. reduce the size of the multichan struct b. re-use original sRGB data for unmodified pixels c. use a look-up table for sRGB to L,u,v d. [painful and inaccurate] interpolate for L,u,v to sRGB It would be great if you could run a line-by-line profiler on the code to see where the time is going. Try using oprofile and kcachegrind to find where cache misses happen. (this is where the --playback option would be great) Windows profiler output might be helpful too. Surely there are some suitable tools... maybe Intel provides some? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 2004-11-26 at 18:54, Bill Kendrick wrote: > Tinting in CVS is a bit broken right now, and VERY slow (on my 450MHz Celeron, > at least). > > Best example is the cartoon butterfly. It doesn't change color (it's always > orange), and takes about 2 seconds between my clicking, and it appearing > on the canvas. > > Ideas? :) > > (This is with the latest CVS for both stamps and code) First of all, the butterfly is looking better than ever for me. It tints perfectly. I'll send you an example. I'd have expected your PC to be very fast at this, because the PC has built-in trancedental math functions in the CPU. You have instructions for sin(), cos(), tan(), and so on. Unlikely to be the problem, but... One thing that may need to change for a PC is the place where a double is compared against zero. Instead of this: if(dst.sat>0) You might be better off with: if(dst.sat>0.0001) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 18:52, Bill Kendrick wrote: > On Fri, Nov 26, 2004 at 06:30:21PM -0500, Albert Cahalan wrote: > > I was just preparing to cache the stamp outline. When the > > stamp changes (new choice, flip, mirror, or scaling), the > > outline needs to be recomputed. There's no need to be > > computing it every time the mouse moves a tiny bit. > > Yes, I've noticed that. :^) On my 450MHz Celeron, the recomputation > takes up QUITE a bit of time. So much so that if I move the mouse > quickly enough, the event handler seems to loose the last few > positions. We may be having a contest for slowest computer. I have a 450 MHz Mac with PC100 memory. Unlike your computer, mine is pushing 32-bit video to a 1600x1024 display, uphill both ways. :-) I have nothing fancier than a bit of basic 2-D acceleration. > This causes the outline to stay where it was, while the "+" mouse > pointer > has moved a few inches away. If I click to place the stamp, of course > (part of) the old outline remains. :^( This is a serious bug. Stamp outline performance improvements will not fix the root cause of this bug; they'll just make the bug harder to reproduce. > > The code in CVS is prepared for this now. Notice that > > update_stamp_xor has been split out of stamp_xor. Now > > there are two reasonable options: > > I tried simply moving the 'update_stamp_xor()' call to whenever the > stamp shape changes (mousewheel rolls or user specifically clicks a > stamp > button on the right). Mousewheel? That doesn't change the stamp AFAIK. Changes would be: 1. startup (very important!) 2. click on new stamp 3. mirror 4. flip 5. scale up 6. scale down Tinting changes the stamp too, but it won't matter for this. > > If this works out well, maybe the low-quality stamp > > outline code will be pointless to keep. > > I notice that's "gone" all of a sudden. ;^) What, "I didn't do it, and nobody saw me." ? > > BTW, there's a bit of a problem with flicker. I suppose > > the solution might involve a canvas-sized bitmap for the > > outline. Then there would never be a need to clear the > > old outline prior to painting the new one; the clearing > > and painting would take place in one operation. > > What's flickering, exactly? flickering == flashing, going on and off, producing an annoying sensation of variable brightness... You don't see it? As a stamp is moved before placement, the outline refresh is visible. I see the outline go and then come back in the new location. This is not good. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Tinting in CVS
Tinting in CVS is a bit broken right now, and VERY slow (on my 450MHz Celeron, at least). Best example is the cartoon butterfly. It doesn't change color (it's always orange), and takes about 2 seconds between my clicking, and it appearing on the canvas. Ideas? :) (This is with the latest CVS for both stamps and code) -bill! [EMAIL PROTECTED] Have I been helpful? http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, Nov 26, 2004 at 06:30:21PM -0500, Albert Cahalan wrote: > I was just preparing to cache the stamp outline. When the > stamp changes (new choice, flip, mirror, or scaling), the > outline needs to be recomputed. There's no need to be > computing it every time the mouse moves a tiny bit. Yes, I've noticed that. :^) On my 450MHz Celeron, the recomputation takes up QUITE a bit of time. So much so that if I move the mouse quickly enough, the event handler seems to loose the last few positions. This causes the outline to stay where it was, while the "+" mouse pointer has moved a few inches away. If I click to place the stamp, of course (part of) the old outline remains. :^( > The code in CVS is prepared for this now. Notice that > update_stamp_xor has been split out of stamp_xor. Now > there are two reasonable options: I tried simply moving the 'update_stamp_xor()' call to whenever the stamp shape changes (mousewheel rolls or user specifically clicks a stamp button on the right). This seems to work great, so far. (I need to make sure the first stamp, when the Stamp tool is first chosen, causes this update, as well) I'll commit in a moment... > If this works out well, maybe the low-quality stamp > outline code will be pointless to keep. I notice that's "gone" all of a sudden. ;^) I wouldn't discount it. We'll need to hear back from LTSP users as to whether the new code works well enough. If not, we should keep that feature around. > BTW, there's a bit of a problem with flicker. I suppose > the solution might involve a canvas-sized bitmap for the > outline. Then there would never be a need to clear the > old outline prior to painting the new one; the clearing > and painting would take place in one operation. What's flickering, exactly? Thx! -bill! [EMAIL PROTECTED] Have I been helpful? http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 17:31, Bill Kendrick wrote: > On Fri, Nov 26, 2004 at 11:24:37AM -0500, Albert Cahalan wrote: > > I'd like to have the stamp controls set up a bitmap for > > the stamp outline renderer. I need to know if I must use > > an SDL surface with locking, or if I can use something > > simpler and faster. > > If what you do interrupts the event loop (as most things do, like saving, > loading, etc.), then if I understand things right (which I admittedly may > not ;^) ), you can probably do it your 'faster' way. > > Though I'm curious, what would that be? > > > Also, you don't happen to be considering alpha-blended stamps under the > mouse before placement...? :) I didn't think of that. It has a bit of a downside though. The outline might be easier to see. I did think of filling in the outline though. I was just preparing to cache the stamp outline. When the stamp changes (new choice, flip, mirror, or scaling), the outline needs to be recomputed. There's no need to be computing it every time the mouse moves a tiny bit. The code in CVS is prepared for this now. Notice that update_stamp_xor has been split out of stamp_xor. Now there are two reasonable options: a. check for stamp changes in update_stamp_xor, and return early (without computation) if no changes b. move the update_stamp_xor call from stamp_xor to the code (flip button, etc.) that causes the stamp outline to need replacement If this works out well, maybe the low-quality stamp outline code will be pointless to keep. BTW, there's a bit of a problem with flicker. I suppose the solution might involve a canvas-sized bitmap for the outline. Then there would never be a need to clear the old outline prior to painting the new one; the clearing and painting would take place in one operation. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, Nov 26, 2004 at 11:24:37AM -0500, Albert Cahalan wrote: > Consider the code for drawing a stamp outline, and the > code for responding to a stamp control button press. > Can those run at the same time? Can one preempt the > other one? Nope. Everything's event driven. Drawing the stamp outline occurs when the mouse is moved (motion event). The stamp change occurs when a stamp button is clicked (mouse click event). > I'd like to have the stamp controls set up a bitmap for > the stamp outline renderer. I need to know if I must use > an SDL surface with locking, or if I can use something > simpler and faster. If what you do interrupts the event loop (as most things do, like saving, loading, etc.), then if I understand things right (which I admittedly may not ;^) ), you can probably do it your 'faster' way. Though I'm curious, what would that be? Also, you don't happen to be considering alpha-blended stamps under the mouse before placement...? :) -bill! [EMAIL PROTECTED] Have I been helpful? http://newbreedsoftware.com/http://svcs.affero.net/rm.php?r=billkendrick ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] reentrancy, thread-safety, etc.
Consider the code for drawing a stamp outline, and the code for responding to a stamp control button press. Can those run at the same time? Can one preempt the other one? I'd like to have the stamp controls set up a bitmap for the stamp outline renderer. I need to know if I must use an SDL surface with locking, or if I can use something simpler and faster. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
