--- Log opened Sat Nov 08 00:00:05 2008
--- Day changed Sat Nov 08 2008
00:00 -!- tatica [n=tatica@nelug/designer/tatica] has quit [Remote closed the connection]
00:00 < genete> how does rotate layer do it? it is taken from the surface to render, right?
00:01 < dooglus> try my binaries now - I've set it to use too few pixel in the subsurface
00:01 < dooglus> zoom in one curve-warped text and you'll see how it's lumpy
00:01 < genete> synfigstudio-fast too?
00:01 < dooglus> yeah
00:01 < genete> yes I've seen that!
00:02 < genete> if you zoom in you get better results
00:02 < genete> what did you do?
00:02 < dooglus> not in this case I don't think
00:02 < dooglus> 	int src_w = w*0.6;
00:02 < dooglus> 	int src_h = h*0.6;
00:02 < dooglus> I told it to use 60% of the width and height of the canvas it's rendering
00:03 < genete> the source code?
00:03 < dooglus> in synfig-core/trunk/src/modules/lyr_std/curvewarp.cpp line 468 - in my directory
00:03 < dooglus> ~/programs/synfig/git/synfig-core/trunk/src/modules/lyr_std/curvewarp.cpp
00:03 < dooglus> I didn't check it in yet
00:04 < dooglus> the rotate layer does it by calculating the pixel width and height it wants in the context surface:
00:04 < dooglus> 	Real pw=(renddesc.get_w())/(renddesc.get_br()[0]-renddesc.get_tl()[0]);
00:04 < dooglus> 	Real ph=(renddesc.get_h())/(renddesc.get_br()[1]-renddesc.get_tl()[1]);
00:05 < dooglus> ie. it uses the same sized pixels for the context as it is trying to render
00:06 < dooglus> kind of makes sense, since rotation won't change the pixel size
00:06 < dooglus> unless the pixels are seriously non-square, and the rotation is 90 degrees or so
00:07 < genete> so we should calculate what's the maximum deformation possible based on distance of the straight line and the lenght of the bline
00:08 < dooglus> distance of the straight line from what?
00:08 < genete> lenght not distance
00:08 < genete> sorry
00:08 < dooglus> ok
00:08 < dooglus> I'm going to go to bed.  I'm pretty tired.
00:08 < genete> ok
00:09 < genete> good work dooglus !
00:09 < dooglus> ~/Desktop/anim/genete4.sifz is a cut-down version of the genete3.sifz
00:09 < dooglus> it shows the same problem - only the top half of the text is rendered unless you zoom in going into 'tiled' rendering
00:10 < dooglus> (once you're doing tiled rendering, each tile has its outline traced you see, giving a better idea of the sub-canvas to render)
00:10 < dooglus> I've put the 60% from earlier up to 500% - it should give better results now - but 100 times slower.  still should be ok for now though
00:11 < dooglus> if you want to tinker with it, copy my ~/programs/synfig/git/synfig-core/trunk/src/modules/lyr_std/curvewarp.cpp into your tree - that's all I've been changing
00:11 < dooglus> goodnight all
00:12 < genete> good night
00:15 < genete> (maybe just add a parameter like "accurate" to allow the user select the % of the size in pixels would be enough for most of the users
00:15 < genete> so it would not be a problem to programming and only when it is needed deep calculation is done)
00:18 < dooglus> that's a kind-of solution to my question (2) - but what about (1)?
00:18 < dooglus> ie. what's the top left and bottom right coordinates of the context to render?
00:19 < dooglus> anyway - enough for today :)
00:19 < genete> tomorrow I'll be out all the day
00:19 < genete> I'll leave the PC turned on
00:21 < dooglus> ok
00:22 < dooglus> you'll turn it off tonight?  I'm logging out now.
00:23 < genete> yes I'll switch off
00:23 < genete> but a bit later
00:23 < dooglus> hey - I made it swap :)  "Swap:      total 7815612     used 720688    free 7094924"
00:23 < genete> rest well
00:23 < genete> you deserve it
00:45 -!- rubikcube [n=kvirc@dslc-082-082-069-130.pools.arcor-ip.net] has joined #synfig
01:41 -!- genete [n=chatzill@79.108.35.41.dyn.user.ono.com] has quit ["ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]"]
01:46 -!- factor [n=factor@ip70-189-85-196.ok.ok.cox.net] has joined #synfig
01:51 -!- pixelgeek [n=chatzill@c-24-20-143-224.hsd1.or.comcast.net] has joined #synfig
01:51 < pixelbot> ( pixelgeek ) pixelgeek Hi there!
03:16 -!- ZanQdo [n=Daniel@201.201.2.22] has quit [Read error: 104 (Connection reset by peer)]
03:16 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
04:33 -!- akagogo [n=carlos@201.230.183.149] has joined #synfig
04:39 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
04:40 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
04:41 -!- akagogo [n=carlos@201.230.183.149] has quit ["Ex-Chat"]
04:42 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has quit ["Don't rest until all the world is paved in moss and greenery."]
04:45 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has joined #synfig
04:49 -!- akagogo [n=carlos@201.230.183.149] has joined #synfig
04:55 -!- rubikcube [n=kvirc@dslc-082-082-069-130.pools.arcor-ip.net] has quit ["KVIrc 3.4.0 Virgo"]
05:14 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has quit ["Don't rest until all the world is paved in moss and greenery."]
05:17 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has joined #synfig
05:18  * pabs3 gonna build synfig with gcc 4.4 as soon as gcc-snapshot installs
05:29 < pixelgeek> showoff....
05:31 < pabs3> :)
05:33 < pixelgeek> I just built 2167
05:33 < pixelgeek> Want to play with the avi importer and curvewarp layer
05:33 < pixelgeek> Maybe both ?  
05:33 < pabs3> have you got an ffmpeg.exe?
05:33 -!- ZanQdo [n=Daniel@201.201.2.22] has quit [Read error: 104 (Connection reset by peer)]
05:33 < pixelgeek> yes - that one does run under windows.  
05:34 < pabs3> cool
05:34 < pixelgeek> (unlike encodedv)
05:34 < pabs3> 2167 has both those features
05:34  * pixelgeek nods
05:34 < pixelgeek> I think there's a poster or two on the forums that will be interested in it too.  
05:35 < pabs3> nasty failures with gcc 4
05:35 < pabs3> 4.4 rather
05:36 < pixelgeek> d'oh - just overwrote the release versions.  (I miss the SVN numbers tacked on the end of the resulting filenames)
05:37 < pixelgeek> Fortunately sourceforge has a copy of them :)
05:38 < pixelgeek> pabs - And did you say it was any format that ffmpeg could read?  Or are there any limitations in the code?  
05:39 < pabs3> any format that ffmpeg can read but the extension needs to be one that synfig knows to associate with ffmpeg
05:39 < pixelgeek> which are....?  
05:39 < pabs3> I'd have to look at the code, don't remember exactly
05:40 < pabs3> its in main.cpp in mod_ffmpeg
05:40 < pixelgeek> OK I'll look
05:42 < pixelgeek> For the record - avi, mpg, mpeg, mov, rm, dv.  
05:42 < pixelgeek> Would it be as simple as adding an extra line there if we wanted to add another?
05:45 < pabs3> should be, yeah
05:46 < pabs3> I don't really think extensions is the right way to determine which importer to use
05:46 < pabs3> on the other hand I don't know what is the right way
05:47 < pixelgeek> Hmm... is gspot opensource?
05:48 < pabs3> doesn't look like it
05:49 < pixelgeek> Four or five years ago, I was bothered by the fact (I'm sure along with many others) that Windows Media Player would refuse to play some files with no indication of "why" - i.e. as to what codec you needed. When I finally ran across a webpage on the subject one day, it suggested loading the entire binary media file into "WordPad" and looking for a four letter code (the "4cc"). As a programmer, it 
05:49 < pixelgeek> seemed absurd to me that such a solution would be suggested when it would be so easy to write an app to acess this "4cc" directly. I was posting on a message forum at the time, under the rather unimaginative nick "Steve G". And there was already a program called EncSpot which identified audio encoders. Somewhere along the line the idea came up that I could write such a program for video and...
05:49 < pixelgeek> ...call it "GSpot". The idea was funny enough that I actually did it. That version 1.0 didn't do much else at the time, but the rest, as they say, is history...
05:49 < pixelgeek> So that's how you do it....
05:50 < pixelgeek> in theory.  I'm sure the lookup table is horrendous to maintain. 
05:51 < pabs3> quite. leaving that to libmagic might be the way to go (at least on Unix)
05:51 < pixelgeek> :P
05:53 < pabs3> looks like libmagic is included in gnuwin32
05:53 < pabs3> so presumably it is doable on Windows too
05:54 < pixelgeek> Sorry - I was thinking magick++
05:54 < pabs3> maybe adding an 'importer' parameter to the import layer would be the way to go, with the default being 'magic' and also having 'extension' one
05:55 < pabs3> http://packages.debian.org/sid/libmagic-dev
05:55 < pixelgeek> Actually ffmpeg should be able to guess the format anyway, right?  
05:55 < pixelgeek> I'm sure it doesn't rely on extension to pick the decoder.
05:55 < pixelgeek> But I can't see an option to dump data on a video file format.
05:55 < pabs3> right, but how do you know which synfig importer to use with the file you are importing?
05:56 < pabs3> ffmpeg can't know about all files - svg for eg
05:56 < pixelgeek> Doesn't it get piped to ppm?
05:56 < pabs3> yep, pipes to ppm, synfig reads from the pipe
05:57 < pabs3> argh, the pthread autoconf configure check isn't portable to gcc 4.4
05:57 < pixelgeek> I guess it's sloppy programming to use the correct filters for the formats you know, ffmpeg to catch the rest, and catch any errors for ones that ffmpeg can't identify ... :(
05:59 < pabs3> ffmpeg isn't a great importer anyway. it'd be better to write a libav importer rather than dealing with the limitations of it
06:00  * pixelgeek looking at the .mts file (AVCHD 1080i) on my HD :)
06:00 < pabs3> (I just patched it up a bit because it was already written)
06:02 -!- akagogo [n=carlos@201.230.183.149] has quit ["Ex-Chat"]
06:02 < pixelgeek> Cool!  Works as advertised!
06:03 < pixelgeek> Painfully slow to render anytime you move to a new frame, but I'm coming to the realization that I need a new PC anyway.  
06:05 < pabs3> cool
06:05  * pabs3 needs a supa-fast desktop
06:11 -!- Yaco [n=Franco@201.255.214.184] has left #synfig ["Saliendo"]
06:11 -!- Yaco [n=Franco@201.255.214.184] has joined #synfig
06:23 < pabs3> pixelgeek: ETL looks for kernel32 and user32, any idea what functions it is using from those?
06:23 < pixelgeek> !
06:23 < pixelgeek> Is it trying to figure out which version of Windows it's running on? 
06:25 < pixelgeek> hmmmmm....  rendering a curvewarped avi file to a gif works with target set to 'auto'(giving you a list of gifs courtesy of imagemagick), but not when set to 'gif'(to get an animated gif with the internal renderer)
06:26 < pabs3> egads
06:26 < pixelgeek> huh - I take that back.  
06:26 < pixelgeek> The Windows gif viewer can't handle it, but firefox can. 
06:28 < pixelgeek> And IE can too.  I don't know why the default gif viewer is having problems.  
06:29 < pixelgeek> bah - can't scp to sourceforge any more.  
06:29 < pixelgeek> Seem to remember having this problem before, but can't remember what I did to fix it.  
06:31 < pabs3> rsync
06:32 < pabs3> they support http, sftp, rsync uploads, but not scp
06:32 < pixelgeek> ah yes. 
06:33 < pixelgeek> grrr..
06:35 < pabs3> hmm, can't find any functions ETL uses from user32
06:43 < pixelgeek> Betcha it was for Windows specific dialogs like file open.  
06:43 < pixelgeek> You know - that wasn't implemented :)
06:44 < CIA-59> synfig: pabs3 * r2168 / (3 files in 3 dirs): Fix the pthread and kernel32 library checks to not check for main. The checks fail on GCC 4.4 otherwise.
06:44 < pabs3> :)
06:47 < CIA-59> synfig: pabs3 * r2169 /ETL/trunk/ETL/handle: Don't enable the use of mutexes on platforms other than Windows unless pthread is available.
06:49 < CIA-59> synfig: pabs3 * r2170 /synfig-core/trunk/src/synfig/time.cpp: 
06:49 < CIA-59> synfig: Always #include <cstdio> when using sscanf.
06:49 < CIA-59> synfig: Fixes an FTBFS with GCC 4.4.
06:50 < pabs3> cool, builds fine with GCC 4.4 now
06:50 < pixelgeek> So I used to drop the experimental drops on synfig.com, but I don't think I can do that now, can I?
06:50 < pixelgeek> Do I have to use the Sourceforge File Release mechanism?
06:51 < pabs3> I recon upload to synfig.org/files
06:52 < pabs3> friggen sourceforge poo
06:54 < pixelgeek> OK
06:56 < pixelgeek> create the dir?
06:56 < pabs3> should already exist
06:56 < pixelgeek> then I'm looking in the wrong place.
06:56 < pabs3> has voria, irc logs and other stuff in it
06:58 < pixelgeek> ah - under wiki...
07:00 < pixelgeek> incoming
07:05 < pixelgeek> http://pxegeek.home.comcast.net/~pxegeek/synfig/doug.gif
07:06 < pabs3> heh
07:07 < pabs3> line 75 of ETL/_trivial.h generates lots of warnings with gcc 4.4 -O4
07:09 < pabs3> hmmm, warning: dereferencing type-punned pointer will break strict-aliasing rules
07:12 < pixelgeek> Windows build of SVN 2167 is available to anyone that feels daring - http://synfig.org/forums/viewtopic.php?f=1&t=3&p=1578#p1578
07:25 < pixelgeek> 'night all
07:33 < pabs3> nite
07:39 < pabs3> dooglus: any idea about that warning? my brain isn't working atm
07:46 -!- pixelgeek [n=chatzill@c-24-20-143-224.hsd1.or.comcast.net] has quit [Read error: 110 (Connection timed out)]
07:57 < pabs3> heh, fixed http://bugs.debian.org/504949 before it was reported
08:03 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has quit [Read error: 113 (No route to host)]
08:07 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has joined #synfig
08:39 < rore> this is for when synfig has sound : http://www.soundsnap.com/ :) 
08:55 < pabs3> almost DFSG-free
09:05 < factor> so your going to add in sound rore
09:11 < rore> factor: sure. It's easy. Just sing during the generated videos, and tadaaa... sound! 
09:12 < factor> ppsft
09:12 < factor> I am going to bed, you keep singing.
09:12  * pixelbot is tired too
09:12 < rore> pabs3: yep, that's what's interesting. The licence is rather permissive 
09:12 < factor> :D
09:13 < rore> factor: hehehe :) g'night 
09:14 < pabs3> there are also these CC-BY ones: http://wiki.laptop.org/go/Sound_samples
09:16 < pabs3> more bits on http://wiki.debian.org/Games/Resources
09:20 < dooglus> pabs3: where did you find a gcc-snapshot with g++-4.4 in it?
09:20 < pabs3> dooglus: Debian sid has it
09:21 < dooglus> newly?
09:22 < dooglus> I just tried installing it, and it depends on gcc-4.3-multilib - but I didn't apt-get update since yesterday
09:22 < dooglus> hmm, updated, but it still depends on the 4.3 multilib
09:23 < pabs3> I'm on amd64, worked fine
09:23 < pabs3> yeah, was uploaded recently
09:25 < pabs3> pkg version is 20081023-1
09:26 < dooglus> that's the same I see.  do you have any gcc packages with 4.4 in their name?
09:26 < pabs3> nope
09:27 < pabs3> no gcc-4.4 source package has been uploaded yet
09:27 < dooglus> ubuntu 8.10 has: Candidate: 20081024-0ubuntu1
09:27 < dooglus> I guess it's the same, or similar
09:27 < pabs3> probably
09:27  * pabs3 bbl
09:37 < dooglus> ubuntu 8.10's gcc-snapshot's g++ -v says:
09:37 < dooglus> gcc version 4.4.0 20081024 (experimental) [trunk revision 141342] (Ubuntu 20081024-0ubuntu1) 
09:37 < dooglus> is that the same trunk revision as in sid?
09:42 -!- genete [n=chatzill@79.108.35.41.dyn.user.ono.com] has joined #synfig
09:42 < dooglus> hi genete 
09:42 < genete> hey!
09:42 < genete> dooglus: you there?
09:42 < genete> ha
09:42 < genete> did you read my email?
09:43 < dooglus> genete: not yet
09:43 < genete> gmail
09:44 < dooglus> email and pidgin are on my home machine, and a lot of the time I'm NX'ed onto your machine in full screen, so I miss IM messages and emails
09:46 < genete> I guessed it, no problem
09:49 < dooglus> my first thought is "when the surface to render is the whole canvas (like genete3.png), the"
09:49 < dooglus> my thoughts often end mid-sentence and make no sense :)
09:50 < genete> so get the idea of the sketches?
09:50 < dooglus> ok "... the bline doesn't 'cross' the tile at all - it's entirely contained within the tile"
09:50 < dooglus> I'm only on the 2nd one at the moment
09:54 < dooglus> do you see what I mean?  it's possible that the bline doesn't cross the edge of the tile at all, but is entirely within it, and we still have problems
09:54 < genete> that case is easy to solve beacuse you can check if both (start and end points of the bline) are inside
09:55 < genete> I assumed it as a "obvious" case
09:56 < genete> in that case depending on the curvature of the segment you can have infinites or ambiguities 
09:56 < genete> too
09:56 < genete> the only solution I see is divide the render tile again until the bline is intersected
09:57 < genete> only one time :)
09:59 < pabs3> dooglus: I think so, yeah
09:59 < genete> oh, I should post the sketches to see if someone else have other idea :)
10:00 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/problem.png
10:00 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/solution1.png
10:00 < dooglus> genete: I don't think it's enough, your proposal
10:00 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/solution2.png
10:00 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/solution3.png
10:00 < dooglus> I think we'll still get not enough rendered in some cases
10:01 < dooglus> pabs3: I don't get any warning about _trivial.h
10:01 < dooglus> pabs3: are you using some -O flag?
10:01 < genete> dooglus: please research those cases
10:01 < genete> as I commented yesterday I have to go out all the day
10:01 < dooglus> genete: suppose in genete3.sifz, the bline just poked outside the frame
10:02 < dooglus> that's one intersection, so you stop subdividing?
10:02 < dooglus> but the inside of the spiral is still unexplored
10:02 < genete> poked? 
10:02 < dooglus> just crossed the border.  if the bline was extended in the top left corner so it crossed the left border
10:04 < genete> that's the case of the entire bline inside the frame
10:04 < genete> and just one cross 
10:05 < genete> but when I talked about crossing I assume that it is only a segment (two vertices only)
10:05 < genete> I assume that you're tsting each segment (iter, next)
10:05 < genete> to see if it crosses the tile or not
10:05 < genete> not the whole bline
10:06 < dooglus> ok
10:06 < dooglus> so if there's any segment in the bline that's not intersecting the tile's edge, we subdivide?
10:07 < dooglus> so if there's any segment in the bline that is at least partially inside the tile, but that's not intersecting the tile's edge, we subdivide?
10:08 < genete> well, if you want to be absolutely sure that you don't get any of the strange cases, yes
10:09 < genete> a segment can do a "s" shape
10:09 < genete> so it can produce strangeness
10:10 < dooglus> can it?
10:10 < dooglus> (produce strangness, that is.  i know it can do an 's' shape)
10:10 < genete> not sure
10:10 < genete> it cannot do a spiral or a doubled 'S'
10:11 < genete> because the nature of the spline
10:11 < genete> hermite
10:11 < dooglus> I didn't understand about what to do with the 'infinities'
10:11 < dooglus> or even what they are
10:11 < genete> nothing to do, it just explains what happens when the tile crosses a spiral bline 
10:12 < genete> the 1,2,3,4 tile is mapped to a non continuous tile
10:12 < genete> passing through +inf, -inf
10:13 < dooglus> +inf in which dimension?
10:13 < genete> I believe that if we can implement this kind of algorithm we can even render self crossing blines
10:13 < genete> in the 'd dimension
10:14 < dooglus> I think there's a point at which the distance from the 'inner loop' of the spirial is equal to the distance from the 'outer loop'
10:14 < dooglus> this distance, 'd' is finite
10:14 < dooglus> I don't see where infinities come into it.  there's a discontinuity - a jump from -d to +d - but no infinities
10:16 < genete> well it is a way of talking
10:17 < genete> just to demonstrate the discontinuity
10:17 < dooglus> ok
10:17 < genete> I have to go (all the day out)
10:18 < genete> please ask here or by email any doubt, comment
10:18 < genete> did the sketches helped?
10:18 < dooglus> yes, it's an interesting idea
10:18 < genete> :)
10:18 < dooglus> I'll look at implementing it if I have time
10:19 < genete> glad to help
10:19 < genete> I don't imagine other solution, if you find other one, let me know
10:19 < genete> would it help on crossing curved gradients?
10:20 < dooglus> I don't think your proposal changes the rendering at all does it?
10:20 < dooglus> it's just a way of knowing how much of the context to pre-render
10:20 < dooglus> (and curved gradients don't care about their context)
10:22 < genete> but when you have a crossing curve gradient (cross over it self) you cannot know if you're on the left of the right of the curve
10:22 < genete> so making smaller tiles would help to discover it
10:26 < genete> have to go, see you later or tomorrow.
10:26 < genete> If I don't return today please shutdown the PC if you finish earlier. 
10:27 < genete> I just keep opened the chatzilla
10:27 < genete> bye! :-P
11:31 -!- rubikcube [n=kvirc@dslc-082-082-075-055.pools.arcor-ip.net] has joined #synfig
11:42 < pabs3> dooglus: -O4
11:42 < dooglus> pabs3: and you see it for every file that uses _trivial?
11:43 < pabs3> yeah, IIRC it gets triggered a lot in synfigstudio
11:44 < dooglus> if you remove synfig-core/trunk/src/synfig/libsynfig_la-valuenode_cos.lo for instance, and 'make' in src/synfig again
11:44 < dooglus> it rebuilds valuenode_cos - which uses _trivial.h
11:44 < dooglus> do you see a warning there?
11:44 < dooglus> (cos I don't)
11:48 < pabs3> nope, I only get the warning when building synfigstudio
11:48 < dooglus> what is an example .cpp file that gives the warning?
11:50 < dooglus> how are you using the snapshot g++ by the way?  you set PATH and LD_LIBRARY_PATH?  or is there a better way?
11:50 < dooglus> export CXX="/usr/bin/ccache /usr/lib/gcc-snapshot/bin/g++"
11:50 < dooglus> export LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib
11:50 < dooglus> ?
11:51 < pabs3> an example is libsynfigapp_la-action.lo
11:51 < pabs3> I followed /usr/share/doc/gcc-snapshot/README.Debian
11:51 < pabs3> export LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
11:51 < dooglus> :)
11:51 < pabs3> export PATH=/usr/lib/gcc-snapshot/bin:$PATH
11:52 < pabs3> src/synfigapp/action_param.h:156 seems to be triggering it:
11:52 < pabs3> /home/pabs/opt/include/ETL/_trivial.h: In member function 'const T& etl::trivial<T>::get() const [with T = etl::loose_handle<synfig::Canvas>]':
11:52 < pabs3> ../../../../code/synfigstudio/src/synfigapp/action_param.h:156:   instantiated from here
11:52 < pabs3> /home/pabs/opt/include/ETL/_trivial.h:75: warning: dereferencing type-punned pointer will break strict-aliasing rules
11:54 < dooglus> ok thanks
11:54 < pabs3> synfigapp/action.cpp is the .cpp file
11:55 < dooglus> "these warnings can be supressed by adding a compile option -fno-strict-aliasing"
11:55 < dooglus> :)
11:57 < dooglus> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
11:57 < dooglus> The rule is enabled by default in GCC at optimization levels at or above O2
11:58 -!- wall[e] [n=chatzill@58.64.55.148] has joined #synfig
12:02 -!- Yaco [n=Franco@201.255.214.184] has quit [Read error: 60 (Operation timed out)]
12:09 -!- Yaco [n=Franco@201.255.214.184] has joined #synfig
12:13 -!- Zelgadis [n=zelgadis@92.124.230.254] has joined #synfig
12:15 < dooglus> genete: looking at curvegradients for blines which cross themself - here's an example: http://dooglus.rincevent.net/random/crossing-bline-curvegradient.png - how could it be improved?  when they cross themselves, some pixels (like 'P' in this example) will be both 'left' and 'right' of the line.  we just color them according to which part of the line they are closest to
12:15 < dooglus> (.sifz available - just replace .png with .sifz in URL)
12:17 < dooglus> pabs3: I'm seeing that warning a lot now too - thanks for the help
12:18 < pabs3> no probs :)
12:27 -!- Yaco [n=Franco@201.255.214.184] has quit [Read error: 60 (Operation timed out)]
12:37 -!- wall[e] [n=chatzill@58.64.55.148] has left #synfig []
12:44 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has quit ["Don't rest until all the world is paved in moss and greenery."]
13:15 -!- Yaco [n=Franco@201.255.238.250] has joined #synfig
13:22 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
13:27 -!- factor [n=factor@ip70-189-85-196.ok.ok.cox.net] has quit [Read error: 104 (Connection reset by peer)]
13:41 -!- factor [n=factor@ip70-189-85-196.ok.ok.cox.net] has joined #synfig
14:40 -!- rubikcube [n=kvirc@dslc-082-082-075-055.pools.arcor-ip.net] has quit ["KVIrc 3.4.0 Virgo"]
14:45 -!- pabs3 [n=pabs@121.221.209.248] has joined #synfig
15:29 -!- pabs3 [n=pabs@121.221.209.248] has quit [Remote closed the connection]
15:33 -!- pabs3 [n=pabs@121.221.209.248] has joined #synfig
16:07 -!- pabspabspabs [n=pabs@121.221.209.248] has joined #synfig
16:09 -!- pabs3 [n=pabs@121.221.209.248] has quit [Read error: 110 (Connection timed out)]
--- Log closed Sat Nov 08 16:18:36 2008
--- Log opened Sat Nov 08 16:26:49 2008
16:26 -!- dooglus [n=dooglus@rincevent.net] has joined #synfig
16:26 -!- Irssi: #synfig: Total of 20 nicks [1 ops, 0 halfops, 0 voices, 19 normal]
16:27 -!- Irssi: Join to #synfig was synced in 29 secs
16:35 -!- Zelgadis [n=zelgadis@92.124.230.254] has quit ["Schastlivo!"]
16:48 -!- pabspabspabs is now known as pabs3
17:48 -!- pabs3 [n=pabs@121.221.209.248] has quit [Read error: 110 (Connection timed out)]
18:13 -!- pabs3 [n=pabs@d122-104-118-138.per9.wa.optusnet.com.au] has joined #synfig
18:54 -!- Yaco [n=Franco@201.255.238.250] has quit [Read error: 54 (Connection reset by peer)]
19:06 -!- ZanQdo [n=Daniel@201.201.2.22] has quit [Read error: 104 (Connection reset by peer)]
19:15 -!- Yaco [n=Franco@201.255.230.78] has joined #synfig
19:22 -!- Harley^ [n=harley@pyx.net] has joined #Synfig
19:23 < Harley^> Howdy :)
19:33 -!- Yaco [n=Franco@201.255.230.78] has quit [Remote closed the connection]
19:33 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
19:52 -!- DreadKnight [n=dread@79.117.48.150] has joined #synfig
19:57 -!- ZanQdo [n=Daniel@201.201.2.22] has quit [Read error: 104 (Connection reset by peer)]
19:58 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
19:59 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has quit [Remote closed the connection]
20:19 -!- xerakko [n=Miguel@debian/developer/xerakko] has joined #synfig
20:20 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has joined #synfig
20:21 < CIA-59> synfig: dooglus * r2171 /synfig-core/trunk/src/modules/lyr_std/curvewarp.cpp: Implement accelerated_render for the Curve Warp layer. It can now warp text and feathered circles, etc.
20:34 < dooglus> genete: I'll shut down your PC now
20:39 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has quit [Read error: 104 (Connection reset by peer)]
20:44 -!- AkhIL [n=akhilman@92-125-60-96-xdsl-dynamic.kuzbass.net] has joined #synfig
20:45 -!- pixelgeek [n=chatzill@c-24-20-143-224.hsd1.or.comcast.net] has joined #synfig
20:45 < pixelbot> ( pixelgeek ) pixelgeek Hi there!
20:53 -!- Harley^ [n=harley@pyx.net] has quit ["Ex-Chat"]
20:54 -!- Harley^ [n=harley@pyx.net] has joined #Synfig
20:58 -!- Harley^ [n=harley@pyx.net] has quit [Client Quit]
21:18 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
21:27 -!- xerakko [n=Miguel@debian/developer/xerakko] has quit ["Ex-Chat"]
22:15 -!- genete [n=chatzill@79.108.35.41.dyn.user.ono.com] has quit [Remote closed the connection]
22:48 -!- Aidenn [n=skyshape@abjr9.neoplus.adsl.tpnet.pl] has joined #synfig
22:48 < Aidenn> hullo.
22:56 -!- factor [n=factor@ip70-189-85-196.ok.ok.cox.net] has quit [Read error: 110 (Connection timed out)]
--- Log opened Sat Nov 08 23:22:06 2008
23:22 -!- dooglus [n=dooglus@rincevent.net] has joined #synfig
23:22 -!- Irssi: #synfig: Total of 20 nicks [1 ops, 0 halfops, 0 voices, 19 normal]
23:22 -!- Irssi: Join to #synfig was synced in 22 secs
23:22 < xerakko> here says that synfig is one of  the 10 best alternate  software!
23:24 < DreadKnight> It's true! :3
23:25 < pixelgeek> They have good taste.
23:26 < pixelgeek> reposting the link so that dooglus's logs catch it - http://www.latercera.cl/contenido/27_69813_9.shtml
23:26 < pixelgeek> xerakko: want to add it to the press page?
--- Log opened Sat Nov 08 23:29:22 2008
23:29 -!- dooglus [n=dooglus@rincevent.net] has joined #synfig
23:29 -!- Irssi: #synfig: Total of 20 nicks [1 ops, 0 halfops, 0 voices, 19 normal]
23:29 -!- Irssi: Join to #synfig was synced in 23 secs
--- Log opened Sat Nov 08 23:46:41 2008
23:46 -!- dooglus [n=dooglus@rincevent.net] has joined #synfig
23:46 -!- Irssi: #synfig: Total of 20 nicks [1 ops, 0 halfops, 0 voices, 19 normal]
23:46 -!- Irssi: Join to #synfig was synced in 21 secs
--- Log closed Sun Nov 09 00:00:37 2008