Thu 29 May 2008 03:45:13 PM UTC, comment #34:
draw_poly is implemented now. So you should be able to see the red rectangle. (HEAD)
|
Tue 05 Feb 2008 02:19:37 PM UTC, comment #33:
I also wrote an OpenGL implementation for invalidated bounds a while ago. Unfortunately it did not yield a performance improvement on my system, which I suspect follows from OpenGL's design. However, I seem to recall I last tested this before we had proper anti-aliasing (which takes a considerable amount of GPU time), so I think I should test it again.
|
Wed 28 Nov 2007 11:33:30 PM UTC, comment #32:
for what concerns draw_poly set_matrix is only used to reset to identity matrix, so shouldn't be a big deal if that's the default.
|
Wed 28 Nov 2007 11:14:25 PM UTC, comment #31:
OpenGL needs to have at least draw_poly implemented before the red square will show up.
I'm not sure about the set_matrix method; I can't see how it's supposed to work. (All drawing methods except draw_poly simply have a matrix as arguments.)
Neither the OpenGL renderer nor Cairo currently implement invalidated regions, although I have a Cairo implementation sitting on my hard drive.
|
Wed 28 Nov 2007 05:19:43 PM UTC, comment #30:
No, still doesn't work.
We're referring to builds with
ENABLE_REGION_UPDATES_DEBUGGING defined.
They should draw a red rectangle around invalidated bounds.
- It works with gtk/agg
- Doesn't work with gtk/ogl, where it gives these messages:
UNIMPLEMENTED: set_matrix
UNIMPLEMENTED: draw_poly
- Kind of work with gtk/cairo
where it gives this message:
UNIMPLEMENTED: set_matrix
and seems to always fully redraw the stage.
|
Sat 10 Nov 2007 02:44:29 PM UTC, comment #29:
Doesn't this work now? Surely renderer improvements in the last year have fixed it.
|
Thu 19 Oct 2006 09:20:04 AM UTC, comment #28:
Unless we come up with a specific test case for problems with the fill style I'd bind the bug summary to the actual visible effect of it.
|
Tue 17 Oct 2006 12:40:07 PM UTC, comment #27:
affermative. I do see (bgtest.swf) the black/wite frame around the textbox but no red rectangle.
Gravity.swf (the jumping smile) has no red rectangle.
The smile outline is red, dunno if it is related in any way.
|
Mon 16 Oct 2006 07:22:58 AM UTC, comment #26:
So you say you see the black/white frame around text boxes but no red rectangle for the invalidated region?
Have you tried gravity.swf? It should show lots of red rectangles.
|
Sat 14 Oct 2006 08:45:20 AM UTC, comment #25:
No, no rectangle yet. I do see the rectangle with gtk/agg though,
this seems to confirm it's a problem with the triangulating render handler...
|
Fri 13 Oct 2006 04:28:37 PM UTC, comment #24:
Don't you see the rectangle now?
|
Fri 13 Oct 2006 04:22:04 PM UTC, comment #23:
Ops, sorry if I reopened. Anyway, original but item was about the 'updated region detection' being broken. It is ok to close this with the new "summary" but it is not ok to close it with the "original" one :)
Should we revert the summary to the original one then ?
|
Fri 13 Oct 2006 04:12:26 PM UTC, comment #22:
Good, so this is okay now :)
|
Fri 13 Oct 2006 04:07:40 PM UTC, comment #21:
It's as you hope... white ! :)
Attached snapshots for all 4 combinations of sdl,gtk/ogl,cairo
(gtk/cairo seems to have another problem, but background still white)
|
Fri 13 Oct 2006 03:58:56 PM UTC, comment #20:
ok, but what's about the text box background? :)
|
Fri 13 Oct 2006 03:56:39 PM UTC, comment #19:
bgtest.swf gives me a light blue/gray background with both SDL and GTK guis over opengl renderer.
The only difference is that text antialiasing with SDL is much better :)
|
Fri 13 Oct 2006 03:50:15 PM UTC, comment #18:
But I also get wrong fill styles when setting a fill style manually (solid one). draw_poly() fills my shape with green instead with white color.
Please check the new attachment with GTK/OpenGL. Does it show a white background and thin black line around the text box?
|
Fri 13 Oct 2006 03:39:12 PM UTC, comment #17:
Ok, I can reproduce the "white" rotating thing.
It's with SDL/opengl.
Instead, there's a success with GTK/opengl.
So, I guess this is a leftover from the time in which we
removed the initial get_movie_info call.
Nobody touched SDL since then I guess...
|
Fri 13 Oct 2006 03:37:17 PM UTC, comment #16:
mmm.. I wonder if this is again a race condition (resize called too late or similar...).
Please try rebuilding after setting startup_frames = m_frame_count
in server/parser/movie_def_Impl.cpp around line 566
|
Fri 13 Oct 2006 03:35:08 PM UTC, comment #15:
The attached bitmap.swf seems to work with opengl now (not with cairo).
What error did you expect ?
|
Fri 13 Oct 2006 03:33:30 PM UTC, comment #14:
Hmm, I think it's more complex. The OpenGL renderer does not render fill styles correctly. See the attached file, I just get a rotating white rectangle.
render_handler_opengl:fill_style_bitmap() gets called, however
Same for gradient fills
|
Fri 13 Oct 2006 03:25:29 PM UTC, comment #13:
bug #17952 seems related. the user reports it to be working now (I think it's my last commit about handling "hairlines"...)
|
Fri 13 Oct 2006 03:20:55 PM UTC, comment #12:
Ok, the problem seems to be another one: Fill style don't work correctly with OpenGL renderer and it's probably a render_handler_tri thing
|
Fri 13 Oct 2006 03:02:11 PM UTC, comment #11:
Ok, it seems that my calls to fill_style_color() and line_style_color() are being ignored. In my case it's filling the text rectangle with a greeen color as opposed with white. There is another shape in the same movie that has the same color so it probably reuses that color.
|
Fri 13 Oct 2006 02:41:58 PM UTC, comment #10:
I think it's twips (since it normally comes from the character definition).
When implementing the first version of the AGG backend line_style_width() was always called with value 1.0 for hairy lines.
The gray line may come from anti-aliasing if it's very thin.
I'm currently compiling Gnash for OpenGL/SDL and test it then.
|
Fri 13 Oct 2006 02:35:28 PM UTC, comment #9:
Other info, setting line_width to 10 draws a "gray" (rather then black) line... should we really use twips?
(yes, hairy line thing should also do as for doxygen comment above that function - btw, shouldn't "hairy" line have a value of 0?)
|
Fri 13 Oct 2006 02:33:51 PM UTC, comment #8:
Setting: line_style_width(10.0f) works for our DefineEditTextVariableNameTest.swf file...
Could you update the doxygen comments about line_style_width()
in render_handler.h to say what's the expected coordinate space ?
(pixels ? twips ? other ?)
|
Fri 13 Oct 2006 02:14:32 PM UTC, comment #7:
Hmm, there have been some changes in render_handler_tri.cpp, see
http://cvs.savannah.gnu.org/viewcvs/gnash/backend/render_handler_tri.cpp?root=gnash&r1=1.3&r2=1.4
Could this be related? I can't see any reason why draw_poly() should not work...
|
Fri 13 Oct 2006 01:53:23 PM UTC, comment #6:
I confirm text border are not displayed !
Check out testsuite/misc-ming.all/DefineEditTextVariableNameTest.swf
(make DefineEditTextVariableNameTest.swf under its dir, needs Ming)
I added a border to the textfield to try this out
(should we open an other bug item?)
Btw, that test also seems to be good for rectangle debugging:
15:52:59: invalidated rect: -40 -40, 2680 280
|
Fri 13 Oct 2006 01:33:20 PM UTC, comment #5:
Also tried with sdl/opengl, same result.
The only thing in common seems to be the triangulating_render_handler to me...
(gtk/cairo also tested)
|
Fri 13 Oct 2006 01:17:33 PM UTC, comment #4:
I verified that draw_poly() is called, and added also fill color so that draw_poly attempts to drow both outline and fill of the polygon. Still no luck. Also tried gtk/cairo, with same results.
|
Fri 13 Oct 2006 11:23:59 AM UTC, comment #3:
Can you please add a debug line into render_handler_tri::draw_poly() to check if it is really called?
It's possible that the draw_poly() function does not work correctly. Please try a movie that contains a text box with a border. draw_poly() is used to draw this border.
|
Fri 13 Oct 2006 11:22:17 AM UTC, comment #2:
WRT expose event... I fixed it for now (might use a better approach but won't pollute this item with that)
|
Fri 13 Oct 2006 10:38:58 AM UTC, comment #1:
Ops, wrong debugging output (my fault).
The real coordinates are:
size is: 4000x4000
At start:
invalidated rect: -1e+10 -1e+10, 1e+10 1e+10
invalidated rect: -1e+10 -1e+10, 1e+10 1e+10
At first click (almost redraw):
invalidated rect: 290 580, 3750 3830
invalidated rect: 290 580, 3750 3830
At clicks on the buttons:
invalidated rect: 1020 1299, 2900 1939
invalidated rect: 1020 1299, 2900 1939
The number actually seems find, maybe is the triangulating renderer that doesn't draw the rect ?
|
Fri 13 Oct 2006 09:43:24 AM UTC, original submission:
I can't see the invalidated region red rectangle with gtk/ogl.
by enabling debugging this is what I see (running simpleguess.swf):
At start:
11:36:32: invalidated rect: -1e+10 -1e+10, -1e+10 1e+10
11:36:32: invalidated rect: -1e+10 -1e+10, -1e+10 1e+10
After a click on "You pick a number" (which redraws most display)
11:39:05: invalidated rect: 290 580, 290 3830
11:39:06: invalidated rect: 290 580, 290 3830
After a click on either of the two buttons (which only redraws the central text area):
11:39:58: invalidated rect: 1020 1299, 1020 1939
11:39:58: invalidated rect: 1020 1299, 1020 1939
Note that total frame size is 4000x4000.
A related bug (should probably file another item) is that hiding the gnash GTK window and then showing it again (expose event) doesn't trigger redraw. I guess this is due to the invalidated rectangle not being updated and thus rendering not happening next FPS iteration.
The test file I'm referrin to is:
https://savannah.gnu.org/bugs/download.php?file_id=10791
|