Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2007-11-06 Thread Udo Giacomozzi
Hello Bastiaan, Tuesday, November 6, 2007, 3:56:03 AM, you wrote: BJ> So I think that the clipping patch should probably be reverted. Agree. Udo ___ Gnash-commit mailing list Gnash-commit@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-commit

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2007-06-06 Thread Udo Giacomozzi
Hello strk, Wednesday, June 6, 2007, 3:50:56 PM, you wrote: s> Well, if the image were created just before calling drawVideoFrame, s> and discarded immediately after, then it would not be a cache. s> Instead, it is kept for later query, so I see it as a cache, and s> it's also renderer-dependent.

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2007-06-06 Thread Udo Giacomozzi
Hello strk, Wednesday, June 6, 2007, 3:38:56 PM, you wrote: s> On Wed, Jun 06, 2007 at 01:24:52PM +, Udo Giacomozzi wrote: >> // NOTE: Assuming that the source image is RGB 8:8:8 >> >> @@ -445,6 +447,9 @@ >> >> image::rgb* frame = static_cast(baseframe); s> If the NOTE an

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp ...

2007-03-07 Thread Udo Giacomozzi
Hello strk, Wednesday, March 7, 2007, 12:37:27 AM, you wrote: s> You can use Intersection(RangeType&, RangeType&) to trim any overflow. Yes, yes, I know. But let me fix the root pf the problem..! :) Udo ___ Gnash-commit mailing list Gnash-commit@gnu

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp ...

2007-03-06 Thread Udo Giacomozzi
Hello Bastiaan, Tuesday, March 6, 2007, 11:46:30 PM, you wrote: BJ> It can be correct only if region.width() < xres. Exactly BJ> Which is not always true; ...most probably because of other reasons. As long getMinX() and getMaxX() are within valid coordinates, we have no problem. In the extreme

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-28 Thread Udo Giacomozzi
Hello Bastiaan, Saturday, October 28, 2006, 12:23:52 PM, you wrote: BJ> Move it into seperate header and implementation files (or BJ> render_handler{.h, .cpp} since it is a renderer thing). I hope I solved this now... Udo ___ Gnash-commit mailing li

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-10 Thread Udo Giacomozzi
Hello Rob, Monday, October 9, 2006, 5:49:10 PM, you wrote: >> Hannes is already working on it. RS> Awesome. I'm too busy to give it a shot right now, and I think it'll RS> be easier for the rest of us if we can test it on our desktops. Hannes has done the GTK GUI and it looks very nice :) He

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, Monday, October 9, 2006, 7:43:29 PM, you wrote: SS> The function relied on a caching interface in the character class. SS> Maybe you have an uncommitted change to the server/character.h ? It was comitted 2 days ago :-) http://cvs.savannah.gnu.org/viewcvs/gnash/server/parser/characte

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello strk, Monday, October 9, 2006, 5:39:17 PM, you wrote: s> No packages for Debian stable. On Debian testing there's a 2.4 s> but with a missing function. So far I've handled to include just s> the missing function in an render_handler_agg_compat.h additional s> file. Need to test (if I handle

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Rob, Monday, October 9, 2006, 5:18:05 PM, you wrote: RS> Let's add a task for it. Bastiaan is the "gui" guy at this time, but I RS> wrote all the original GTK support, including the gui library. The issue RS> here is separating the GTK parts from the GtkGLExt parts as write now RS> they're

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, ok, I talked with Hannes and he is currently working on it :-) Udo Monday, October 9, 2006, 4:01:08 PM, you wrote: SS> Bastiaan is working on Gui cleanups, so far he's been the Gui guy :) SS> I think we can open up a task for this on savannah and see who wants SS> to work on it.

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, Monday, October 9, 2006, 3:00:05 PM, you wrote: SS> I was just tryin to make it buildable. If you prefer I can just SS> avoid fixing anything myself but rather either send an email to SS> gnash-dev, or to yourself, or file a bug report. Let me know SS> what do you like more :) I not

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, Monday, October 9, 2006, 3:08:47 PM, you wrote: >> SS> /usr/include/agg2# grep render_scanlines_compound_layered * SS> I'm using debian packages. I'm sure getting AGG from sources would SS> work better, but I'd like people to be able to use packaged dependencies, SS> that's why I as

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, Monday, October 9, 2006, 3:04:09 PM, you wrote: SS> No results from this search: SS> /usr/include/agg2# grep render_scanlines_compound_layered * seems like you're using a RPM version? Try the sources from http://www.antigrain.com/download/index.html They should compile just fine.

Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler_agg.cpp

2006-10-09 Thread Udo Giacomozzi
Hello Sandro, Monday, October 9, 2006, 3:00:05 PM, you wrote: SS> I was just tryin to make it buildable. Hmm. I have no problems building the current version. You were commenting out a (currently) unused function There are other two long but unused functions, but please don't kill them :-) SS>