--- Log opened Wed Mar 28 00:00:02 2007
00:19 -!- pxegeek [n=Miranda@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
00:19 < dooglus> hey
00:37 < pxegeek> Hey - sorry was distracted by slashdot
00:38 < dooglus> me too :)
00:38 < dooglus> your crash from yesterday has been keeping me busy
00:38 < dooglus> I can't work out what's going on
00:39 < pxegeek> sorry
00:39 < pxegeek> I'm glad you saw it though.  
00:39 < dooglus> it seems there's nothing special about that .sif file
00:39 < dooglus> pretty much any .sif file will crash if you zoom in and out enough
00:39 < pxegeek> I was beginning to think I was going to have to reinstall XP
00:40 < pxegeek> I wouldn't be surprised if there was a render bug in there somewhere. 
00:40 < dooglus> I think your use of ALPHA_OVER composition makes it more likely to crash though
00:40 < pxegeek> Mine does seem to crash when repainting the window
00:40 < dooglus> I'm beginning to think that maybe it's some race condition between the threads
00:40 < dooglus> I think it's using multiple threads to render the display
00:41 < pxegeek> Sweet! 
00:41 < dooglus> and I'm wondering if they're trampling each other's memory
00:41 < pxegeek> (assuming it works)
00:41 < dooglus> I see some memory corruption, anyway:
00:41 < dooglus> >> mixing (R:1.709 G:98253151854172432998586264779227136.000 B:1.685 - A:0.000) with 0.54 of (R:1.709 G:98253151854172432998586264779227136.000 B:1.685 - A:925188032036864.000) gives a_out = 425559788093440.00
00:41 < dooglus> tht'a VERY bright colour :)
00:41 < dooglus> that's
00:42 < dooglus> maybe this is what they mean by high dynamic range?
00:42 < pxegeek> Used to be it would crash when I using the controls - GTK would be crash or cause errors - but Atrus builds \fixed that
00:42 < pxegeek> Very Green
00:43 < dooglus> does http://dooglus.rincevent.net/synfig/crash-alpha-over.sif cause the crash for you?
00:43 < dooglus> it's a single rectangle...
00:44 < pxegeek> Well it loaded, but I don't see a rectangle
00:45 < dooglus> you see it in the layer dialog
00:45 < pxegeek> Yes
00:45 < pxegeek> you want me to zoom it?
00:45 < dooglus> yes please
00:46 < pxegeek> Took it all the way to 1600% slowly
00:46 < dooglus> hmm
00:46 < dooglus> ok
00:47 < dooglus> did you see anything other than the checkboard pattern while zooming?
00:47 < pxegeek> Clicked back fast and got to 171% before it crashed/  Canvas size unaltered from how it opened
00:47 < pxegeek> Just the dotted line and the ducks
00:48 < dooglus> I see the occasional corruption, like this:
00:48 < dooglus> http://dooglus.rincevent.net/synfig/corrupted-display.png
00:49 < dooglus> in the top left corner, there's a broken black line
00:49 < pxegeek> Oooh I saw that the other day when I was working on the icons
00:50 < dooglus> shouldn't be there - seems to be random corruption
00:50 < pxegeek> I saw it on the right hand side about the same distance down
00:50 < pxegeek> Yup
00:50 < dooglus> eventually it ends up somewhere more dangerous and crashes the program
00:50 < dooglus> I can't see any way to tell it to use a single thread.
00:50 < dooglus> that woul be a good way to test whether it's the multi-threading that's causing the problem
00:51 < pxegeek> I can turn off hyperthreading on my PC, but I can't remember if that leaves me with one or two threads
00:52 < dooglus> I'm guessing it'll use software threads anyway if you do
00:54 < pxegeek> True that
01:03 < pxegeek> When it crashes for me, it looks like the tiles haven't finished painting
01:03 < dooglus> they paint in an apparently random order?
01:03 < dooglus> they do here
01:03 < pxegeek> http://pxegeek.home.comcast.net/synfig/crash.JPG
01:03 < dooglus> that's what makes me think it's using multiple threads
01:04 < dooglus> did you try telling MS about the problem?
01:04 < dooglus> maybe they can debug it - 'cos I can't!
01:04 < pxegeek> I mentioned it to pabs, but he agreed that they probably wouldn't do anything with it.  
01:05 < pxegeek> I think they need to see several thousand people reporting the same issue before they do anything
01:05 < pxegeek> Be a while before we have that problem w/ synfig
01:08 < pxegeek> Grr...  and the other thing that happens occasionally when it crashes is that I lose all the dialog boxes
01:09 < pxegeek> They're still on the menu bar, but not visible on screen.  Time to delete the config file.
01:10 < dooglus> yes, I've seen that too
01:10 < dooglus> you can get them back from the menu though
01:10 < dooglus> I don't delete the config file
01:10 < pxegeek> I can never remember what goes where - I find it easier to delete and let the default kick back in
01:15 < pxegeek> Did you get any more details on the windows build from Atrus?
01:21 < dooglus> nope
01:22 < dooglus> I'm off.  goodnight :)
01:45 -!- teak [n=teak@24.244.163.157] has joined #synfig
01:45 < teak> evening all
01:45 < teak> I just ran into something I thought was strange.
01:45 < teak> I was going to two of my sif files and saving the two saucer designs.
01:46 < teak> I deleted everything but the saucer, changes the time to 0 and saved with a new name
01:47 < teak> cool... now the strange thig was that the key frames were still in the file when it was 0f... Is this expected / proper behaviour?
01:51 < pxegeek> Cool!
01:51 < teak> what?
01:51 < pxegeek> What you are seeing!
01:52 < teak> is that proper?
01:52 < pxegeek> I haven't seen it, but I've only created timelines, not eliminated them
01:52 < teak> Ihad to delete the keyframes manually for my purposes...
01:53 < teak> just wondering... perhaps there is some use for the behaviour I have not become aware of yet...
01:53 < pxegeek> I don't think any of the developers are on right now
01:53 < pxegeek> Dooglus just signed off, and I haven't seen pabs yet
01:53 < pxegeek> Could be...
01:53 < teak> i see dooglus who is doing bug swapping at least (well he is logged in at any rate)
01:54 < pxegeek> He said he was going to be half an hour ago
01:54 < pxegeek> going to bed half an hour ago
01:54 < teak> k
03:23 -!- pabs3 [n=pabs@dsl-58-7-192-148.wa.westnet.com.au] has joined #synfig
04:40 -!- teak [n=teak@24.244.163.157] has quit ["Leaving"]
06:32 < pabs3> ooh: http://www.andreasn.se/blog/?p=44
07:24  * pabs3 works on mod_mng some more
07:30 < pxegeek> dooglus - if you see this, I was working on synfig most of this evening, and it's been the most stable I've ever seen it - I had it at 100% zoom only
07:32 < pxegeek> More anecdotal evidence of something weird in rendering non-default zoom levels...?
07:37 < pxegeek> pabs - so Tango Friday means that at some point synfig's default icons will get updated?  the file open, save, etc?  
07:37 < pxegeek> if so - yay!
07:37 < pabs3> yup
07:38 < pxegeek> Do you have any idea of how long from commit to showing up in a stable GTK release?
07:39 < pxegeek> Are we talking days, weeks or months?  
07:41 < pabs3> hmm
07:41  * pabs3 looks at release dates on gtk.org
07:42 < pxegeek> Either way, I probably need to pick up the pace
07:43 < pabs3> gtk seems to release new stable versions about once a year, followed by bugfix releases
07:43 < pabs3> I'd expect one mid-year this year if things stay the same
07:44 < pabs3> not sure if the 6-monthly gnome releases affect that
07:49 < pxegeek> OK, so we may have 'til June to sync up the tango icons....
07:49 < pxegeek> I won't count on it!
07:49 < pabs3> :)
07:49 < pxegeek> bedtime - 'night
07:50 < pabs3> could always ask on tango-artists, may get a tango friday devoted to synfig :D
07:50 < pxegeek> I'm just getting to the fun ones!
07:51 < pxegeek> I'm going to solicit suggestions for some
07:51 < pxegeek> Like Timeline
07:51 < pxegeek> Meta
07:51 < pxegeek> Smooth move
07:52 < pxegeek> Child
07:52 < pxegeek> Too abstract for my mind to come up with icons
07:52 < pxegeek> Anyway need to get some sleep
07:52 < pabs3> gnite :)
07:53 < pxegeek> 'nite
07:53 -!- pxegeek [n=Miranda@c-71-59-140-184.hsd1.or.comcast.net] has quit []
09:57 < dooglus> pabs3: bug [ 1689329 ] 'studio crashes zooming in to canvas' has got me stumped
09:58 < dooglus> I've tried gdb, valgrind, simplifying the test case, and everything else I can think of
09:58 < dooglus> but I'm getting nowhere
09:58 < dooglus> any ideas how I can proceed?
09:58  * pabs3 looks
10:00 < pabs3> it crashed here even without maximising
10:00 < pabs3> *** glibc detected *** free(): invalid next size (normal): 0x08e08588 ***
10:01 < dooglus> it seems pretty random
10:01 < pabs3> synfigstudio: color.cpp:266: synfig::Color blendfunc_STRAIGHT(synfig::Color&, synfig::Color&, float): Assertion `out.is_valid()' failed.
10:01 < dooglus> yes
10:02 < pabs3> that second crash was using the scrollbar on the nav window
10:02 < dooglus> memory is getting trashed somehow
10:02 < dooglus> and you're seeing the symptoms of it
10:02 < pabs3> yeah
10:02 < dooglus> what we need to do is find the cause of it
10:02 < pabs3> any luck with valgrind?
10:02 < dooglus> no
10:03 < dooglus> I pasted valgrind's report in the bug
10:03 < dooglus> I'm thinking the problem is caused by the threads not playing nice with each other
10:04 < pabs3> quite possibly
10:04 < dooglus> I don't know if you remember how the hex colour edit box started studio crashing when I added it
10:04 < dooglus> but that seems to be the same area
10:04 < pabs3> yeah
10:04 < pabs3> what was the fix for that again?
10:05 < dooglus> I didn't find a fix, just a workaround
10:05 < dooglus> the bug was provoked by adding a new member to 'class Color'
10:05 < dooglus> and the workaround was to change the new member to a static member
10:06 < dooglus> 'class Color' has 2 different implementations, depending on whether OpenEXR is being used or not.
10:06 < dooglus> they both crash the same
10:07 < pabs3> hmm can't reproduce the crash in valgrind
10:08 < dooglus> it doesn't happen every time
10:08 < dooglus> maximising the canvas helps
10:08 < pabs3> I see lots of invalid writes of size 4
10:08 < pabs3> yep
10:09 < dooglus> are the invalid writes around color.cpp?
10:10 < pabs3> invalid reads at 0x82B1BB8: synfig::Color::Color(synfig::Color const&) (color.h:234)
10:10 < dooglus> yes, I see those
10:11 < dooglus> invalid reads in Color's copy-constructor
10:11 < pabs3> invalid writes at 0x42DC433: etl::generic_pen<synfig::Color, synfig::Color>::put_value(synfig::Color const&) const (_pen.h:204)
10:11 < pabs3> but the invalid reads happen before the writes
10:11 < dooglus> how can a copy-constructor read illegally?
10:12 < dooglus> it's copying an existing Color object - isn't that always legal?
10:12 < pabs3> well, you could pass it a pointer/reference that points at some other memory
10:13 < dooglus> but we're not calling it explicitly
10:13 < dooglus> it gets called automatically, when objects need to be copied
10:13 < dooglus> (from a blend_XXX method, as I remember)
10:14 < dooglus> are you using that large-ish icon from pxegeek?
10:14 < dooglus> or the cut-down .sif file?
10:14 < pabs3> cutdown one in your first comment
10:16 < dooglus> ok
10:16 < dooglus> it seems that editing the file to use almost any blend method still causes it to crash
10:17 < pabs3> yeah?
10:17 < dooglus> I've not seen it crash with blend methods 1, 2, 3, 4, 14 or 18, but all the rest I have
10:18 < dooglus> but that doesn't make any sense.  4 is 'ADD' and 5 is 'SUBTRACT'...
10:18 < dooglus> why would one crash and not the other!
10:20 < pabs3> hmm
10:20 < dooglus> I think I just hadn't tried hard enough.
10:20 < dooglus> they both crash now...
10:23 < dooglus> ok.  every value of blend_method from 2 to 21 has crashed for me now.  only '1' (STRAIGHT) hasn't
10:25 < pabs3> 1 doesn't crash here either
10:28 < dooglus> it seems that the crash needs the rectangle to be 'invert=true'
10:28 < dooglus> ie. it's something to do with the area outside the rectangle that's crashing it
10:28 < dooglus> and blend_method=1 seems to cut off the outside of the rectangle
10:50 -!- crazy_bus [n=philip@139.168.109.46] has joined #synfig
10:58 < pabs3> got me stumped
11:00 < dooglus> :)
11:01 < dooglus> me too
11:01 < dooglus> what needs to be done to make functions thread-safe?
11:01 < dooglus> is there any implications of these blend_XXX functions being static member functions, for instance?
11:03  * dooglus reads http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm
11:07 -!- igli [n=igli@unaffiliated/igli] has joined #synfig
11:12 < dooglus> igli: can you cast any light on bug #1689329?  it's got me stumped.  see the bottom half of http://jabber.deepdarc.com/logs.php/%23synfig%40freenode.irc.deepdarc.com/20070328 for the discussion so far...
11:13 < igli> heh i'll have a look, not sure how much good it'll do ;)
11:17 < igli> hmm let me dig out the src, i don;t know the code very well
11:18 < igli> color.h:258 is the error point?
11:23 < dooglus> that's where gdb usually complains, yes
11:23 < dooglus> but it's not clear if that's where the error actually happens.  I think that's just the first place it causes a serious problem
11:24 < igli> ok just updated to 389; looks like a corrupt ptr
11:24 < dooglus> the Color &c reference?
11:27 -!- crazy_bus [n=philip@139.168.109.46] has quit [Remote closed the connection]
11:28 < igli> heh sorry had to deal with something. haven't even opened a file yet (just woke up ;)
11:28 < dooglus> no worries
11:30 < igli> er doh! i am looking at synfig, not studio
11:31 < dooglus> that's right: synfig-core/src/synfig/color.{cpp,h}
11:32 < igli> k looks like rectangle.cpp is actual caller?
11:35 < dooglus> Rectangle::accelerated_render(), yes
11:37 < igli> just out of curiousity: if((min[0] > max[0]) ^ (pw < 0))swap(min[0],max[0]); ?
11:40 < dooglus> doesn't the comment above it explain everything?
11:41 < igli> er there isn't one. why not just use && ? (not that this is prob)
11:41 < dooglus> it would be twice as long to use && I think?
11:41 < dooglus> a ^ b   becomes (a && !b) || (!a && b)
11:42 < igli> if ((min[0] > max[0]) && (pw < 0)) // eh?
11:42 < dooglus> isn't ^ *exclusive* OR?
11:42 < igli> that's effectively what that does
11:42 < igli> i thought it was exp
11:43 < igli> hmm maybe i should check ;)
11:43 < dooglus> a^b: Bitwise XOR (exclusive OR) of a and b 
11:44 < igli> hmm ok
11:45 < dooglus> I think what it's saying is that if exactly one of "min  > max" and "width < 0" is true, then swap min and max
11:46 < igli> cool, didn't know that was xor (been years since i did any c++)
11:47 < dooglus> I think it's the same in C
11:47 < dooglus> not that I've ever felt the need to use it, either
11:49 < igli> hehe
11:50 < igli> dooglus: you must come to #friendly-coders sometime; it's a chilled atmosphere, altho i'm dealing with a noob atm (:roll:)
12:09 -!- igli [n=igli@unaffiliated/igli] has quit [Read error: 104 (Connection reset by peer)]
12:09 -!- igli [n=igli@unaffiliated/igli] has joined #synfig
13:12 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
14:19 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
15:16 -!- igli_ [n=igli@82.153.38.176] has joined #synfig
15:32 -!- igli [n=igli@unaffiliated/igli] has quit [Read error: 110 (Connection timed out)]
16:12 -!- igli_ is now known as igli
16:28 < nox-Hand> igli: MaŽke up yer mind
16:29 -!- zipola [n=zipola@zip.kortex.jyu.fi] has joined #synfig
16:30 < igli> heh don't ask me nox-Hand, net connection did it :)
17:17 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
17:35 -!- omry [n=omry@l85-130-137-160.broadband.actcom.net.il] has quit [Read error: 131 (Connection reset by peer)]
17:37 -!- omry [n=omry@l85-130-137-160.broadband.actcom.net.il] has joined #synfig
17:45 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
17:51 -!- teak [n=teak@24.244.163.157] has joined #synfig
17:53 < teak> just uploaded a chroma key test to youtube, will post url when it goes live...
17:59 -!- pabs3 [n=pabs@dsl-58-7-192-148.wa.westnet.com.au] has quit ["Don't rest until all the world is paved in poems."]
18:14 -!- Netsplit pratchett.freenode.net <-> irc.freenode.net quits: zipola
18:14 -!- Netsplit over, joins: zipola
18:22 < teak> http://www.youtube.com/watch?v=BnmzWrGoNrM
18:22 < teak> Bingo.
18:22 < teak> Kind of works
18:22 < teak> animation overlaid on digital video...
18:39 < dooglus> nice :)
18:44 < teak> I just tried another test with no background in the sif instead of a gree background
18:45 < teak> the dv rendered with a grey backgroundthough...
18:46 < teak> getting the live and animation in "sync" will be a lot of work though...
18:47 < dooglus> you could use a series of screenshots I guess
18:47 < dooglus> if you can get timestamps on the images
18:47 < dooglus> but that's still a lot of work
18:48 < teak> oh, it is doable - wouldbe easier if one could import the video into synfigstudio...
18:49 < teak> some day
18:51 < teak> that was fun though...
19:38 -!- teak [n=teak@24.244.163.157] has quit ["Leaving"]
22:14 -!- pxegeek [n=Miranda@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
22:19 -!- Netsplit pratchett.freenode.net <-> irc.freenode.net quits: pxegeek, @ChanServ, zipola, omry
22:19 -!- Netsplit over, joins: @ChanServ, pxegeek, zipola, omry
22:33 -!- pxegeek [n=Miranda@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 110 (Connection timed out)]
22:53 -!- pxegeek [n=Miranda@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
22:53 -!- teak [n=teak@24.244.163.157] has joined #synfig
23:32 -!- dooglus_ [n=chris@r6ac156.net.upc.cz] has joined #synfig
--- Log closed Thu Mar 29 00:00:02 2007