Penguin.SWF

Looks like there might be a problem the client string with Xorg running the radeon driver (which _is_ accelerated).

$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_visual_select_group
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x TCL
OpenGL version string: 1.3 Mesa 7.1
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format,
GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SUN_multi_draw_arrays,
GL_S3_s3tc

[ Thanks for the data. -Mike M. ]

Blaming this on compiz seems a bit unfair - I'm going to assume the real problem is that GL compositing is very broken on most configurations, but this has nothing to do with compiz and everything to do with the poor state of Linux graphics drivers.

GL compositing with compiz and nvidia drivers usually works fine; I've been using it on all of my computers with no problems for ages now (so Geforce 5200, 6800 and 8600 cards). Is compiz detected and this feature disabled? If so, how is this detection done? Even running without compiz, I don't seem to see any benefit from flash's hardware acceleration under Linux.

It'd be cool if some more was written on the exact acceleration that takes place, how it differs from Windows, and what methods are used to detect when acceleration can be used.

Currently, Windows flash under wine performs much better than Linux flash, for stand-alone applications at least.

This limitation also apply if you use any other composite-enabled Window Manager (as Metacity with composite option)?

[ Not currently, but perhaps we just don't have enough data yet. -Mike M. ]

You didn't said anything about the most requested features, wmode and v4l2, what about those?

Are you working on it? Or should I loose my hopes.

server glx vendor string: SGI
server glx version string: 1.2
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 TCL
OpenGL version string: 1.3 Mesa 7.0.3-rc2

Oh, look. Accelerated 3D drivers with SGI as the vendor string, but still more than fast enough for me to smoothly play Frets on Fire, meaning more than enough to improve Flash's 2D scaling acceleration. You honestly couldn't think of a way better way to determine whether the rendering is software or not than to grep for some apparently only tangentially related string and hope the correlation was good enough? There seriously isn't a better mechanism to determine whether or not the graphics are accelerated?

[ There are more accurate solutions, and we tried to use them; unfortunately, they crashed on certain software drivers on several different Linux distributions. Thanks for the data; this should help us develop a better solution. -Mike M. ]

...and where is the most requested feature?! Stop slacking off...

Thanks. I'm glad that you're now being clear on the requirements for GPU acceleration, and the provisos for it. Hopefully this means we can move forward and solve problems like the radeon acceleration mentioned above. It may not be as satisfying as a new feature, but it's still a significant step.

Personally, I'm glad that I now understand why my Geforce2 card won't (and probably never will) offer hardware acceleration in flash (missing GL_ARB_fragment_shader and GL_EXT_framebuffer_object). And also why xv won't help for video, even if this card is more than capable of playing standalone .flvs.

New Intel cards also have SGI as the client vendor string, yet are more than capable for this kind of video acceleration..

Maybe a simple benchmark the first time flash is started would help to determine if it is hardware accelerated or not.

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions: ...
client glx vendor string: SGI
client glx version string: 1.4
...

I'm using an ATI card with the fglrx driver. All fully DRI accelerated. Why aren't you testing on the "direct rendering: Yes" flag? Or is this the test that causes the crashes. Maybe there should be some hidden option available for experienced users to override the test and force acceleration.

[ Yep, the direct rendering test is the one that crashes. I'll be looking at better solutions in light of this thread. -Mike M. ]

I sevearly doubt compiz is not to blame here, what compiz in my experiance *can* do is make buggy code much more visable, if your doing things the wrong way it all throw much more of a fit.

lets face it, if high profile games like quake: enemy territory and such can work flawlessly with compiz, along with pretty much every other game i have ever tried (even through wine) then i doubt its fair to put the blame there.

lets hope you fix your code for final, i'm sure not disabling my pretty for your product

"Unfortunately, the Flash Player can not easily make use of this since Sorenson, On2, or H.264 video data -- even though it is decoded as YUV -- has to be converted to RGB and possibly combined with other graphical elements. This is why RGB scaling via OpenGL is the future of Flash."

And converting back to YUV space after compositing, so that scaling can use hw acceleration - is that difficult concept to come up with? Jesus...

I'm using intel graphic driver for my X3100 card and the vendor is also SGI. There must be some better way to detect whether the graphic card is accelerated...

What's wrong with checking for:
direct rendering: Yes for hardware acceleration
and no for software?

[ Because the check crashes on some systems. -Mike M. ]

Hi, just wanted to let you know that I have an ATI Mobile Radeon X1300 with DRI enabled and I have all the prerequisites for Flash fullscreen OpenGL acceleration except the client vendor string:

$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1300
OpenGL version string: 2.1.7415 Release
OpenGL extensions:
GL_AMD_performance_monitor, GL_ARB_depth_texture, GL_ARB_draw_buffers,
GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_float,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,
GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader,
GL_ATI_meminfo, GL_ATI_separate_stencil, GL_ATI_texture_compression_3dc,
GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_EXT_abgr,
GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array,
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
GL_EXT_framebuffer_object, GL_EXT_gpu_program_parameters,
GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texgen_reflection, GL_EXT_texture3D,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array,
GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_texgen_reflection,
GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod,
GL_WIN_swap_hint, WGL_EXT_swap_control

I added XVideo support to Gnash; it's not that difficult. Most video cards support an RGB format, and if they don't then the algorithms to do rgb->yuv are fairly simple and fast. Although there are other advantages to using OpenGL.

Hi, my name is Corbin, I'm one of the Mesa developers working with AMD to support Radeon GPUs.

We just finished code supporting the R500 chipsets, which means we support all Radeons below the HD 2000, including GPUs still being shipped today in modern laptops.

Since we are using Mesa, our glx client and server identify as "SGI". A more robust check would be to see whether or not the OpenGL renderer string is "Mesa X11 Indirect", as that is the indicator of (in)direct rendering.

While it might be nice to consider ATI and nVidia as the bastions of stable OpenGL stacks, the truth is that many users prefer the open-source Mesa-based stack to ATI's fglrx stack in terms of stability and performance, and furthermore vendors like Intel and VIA are only supported through Mesa and not through proprietary drivers.

Thank you for your time.
~ C.

[ Thanks for yours; I'll be in touch. -Mike M. ]

The 3D acceleration detection will also fail with Intel GPUs:

server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.4
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965G 4.1.3002
OpenGL version string: 1.5 Mesa 7.0.3

Some lines from glxinfo on card *with full OpenGL-acceleration* support using the latest ATI fglrx-driver:
...
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
...
client glx vendor string: SGI
client glx version string: 1.4
...
...
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.1.7537 Release
OpenGL extensions:
...
...

That "grep for SGI"-test of yours does not seem like the best solution, as this output comes from machine with full OpenGL/glx acceleration set up. Doesn't look like I'll be getting any Flash-acceleration, a shame really, since I don't use Compiz and Flash could need some beef-up for it's video scaling performance.

Oh, and forgot to mention, the card+driver I'm using (ATI X1400 + fglrx) seems to support all required OpenGL-extensions, even though you detect it as unusable because of the glx vendor string:

$ glxinfo|grep GL_ARB_multitexture
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
$ glxinfo|grep GL_EXT_framebuffer_object
GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object,
$ glxinfo|grep GL_ARB_shader_objects
GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow,
$ glxinfo|grep GL_ARB_shading_language_100
GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow,
$ glxinfo|grep GL_ARB_fragment_shader
GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_half_float_pixel,

"Yep, the direct rendering test is the one that crashes."

I don't quite see how this is possible since it's just a single function call in a GL context, and Wine even does it as part of its initialization (and it doesn't require GL acceleration).

GLXContext ctx = glXCreateContext(dpy, ..., True);

if(!glXIsDirect(dpy, ctx))

   ...;

While it's possible those may throw X errors, which will terminate an unsuspecting app by default, they are very easy to capture with basic Xlib calls.

It's also interesting to note that almost all accelerated drivers have SGI in the client GLX client string, thus won't accelerate, except nVidia. But nVidia cards have trouble getting acceleration working, too..

[ Actually, I was mistaken. The above code works correctly; it's the ensuing glXDestroyContext() that crashes. -Mike M. ]

THANK YOU! Why haven't you given these details before?
I finally figured out why my desktop fullscreen rendering was so slow (although Quake 3 plays at desired frame rate of 125fps).
I've just tested Astro on a laptop with more recent Nvidia card and got really smooth fullscreen rendering (small bug when quitting fullscreen mode, main window ain't refreshed at all, I'll report this one).
So too bad my GeForce4MX doesn't allow fullscreen where it could (not should!). Let me know if you want glxinfo.

-Swift

How can I take advantage of this on 64-bit Linux?

Ouch.

But Compiz itself does the direct rendering check. If they got it enabled, surely the system passed!

I suggest Adobe quickly figure out a way to get GPU acceleration working with Compiz. What's the point of adding features that a quickly shrinking percentage of Linux users can make use of? Do you think many Vista users would disable Aero just to make use of features in a browser plugin? Sheesh!!!

Hopefully Google will get sick of this anti-OSS crap from Adobe and abandon flash altogether on youtube as they have with the Apple/iphone/AppleTV and give everyone one less reason to bother installing Flash.

Seriously... Fix WMODE and do something about the crashes and apparent pulseaudio conflicts instead of adding feature that will be USELESS to most of us. I can live without GPU acceleration for now if theses other issues are fixed.

First I'd like to thank you for evolving the Flash player on Linux.
I hope one day I could play flash videos without sound desynchronization. As far as I could read, it's not for this version yet, but it'll happen soon!
Could it be possible to add an option to the flash plugin so that it would force the hardware acceleration, so much for the instability? If the user adds this option, he knows to what he's heading to.

Good luck for the future!

Thanks for the YUV/RGB explanation. I never knew about this until I saw it mentioned over on http://lwn.net/Articles/282846/ . It's a killer on old machines but at least I now know why. These sorts of entries are invaluable!

It's also worth noting that Intel cards like the i945 don't implement shaders in openGL so hopefully that will head off people mentioning that flash on such cards don't seem to use the GPU.

You knew this one was coming: where's the 64bit version of flash? Would like to see that before anything else (maybe except the "flash always covers drop-down menu's so those menu's become invisible). Thank you for your efforts.

So I checked I have every requirement you mentioned, I use KDE without the Composite extension enabled. Yet my fullscreen video is still slideshow, I know you mentioned content will need to be specifically authored, but I still feel very left out by adobe not giving me a smooth FULLSCREEN experience on a very highend IntelCore2 with a 1920x1200 resolution, where on windows it works. Essentially you are saying full screen will work if they specifically author it, well NO ONE IS, how are you planning on supporting fullscreen for all of the rest of flash content?!?!? I don't care if you are using gpu accelleration or not, fullscreen video should work, you should atleast have a timeline of when it will be supported.

>Answer: Because Xv scales YUV >data. Flash Player operates on >RGB data.

I don't think this is true.

From what I can tell, both my cards support an XV_IMAGE encoding, and RGB is a valid Xv image format, so they should both work. One is an Geforce4MX with the nvida drivers the other is a radeon with the free drivers.

It seems possible that many drivers wouldn't support RGB scaling, though it looks like many do.

I didn't actually try to do RGB scaling, so it's possible that it's broken.

[ I've done some tests and I have yet to find a card that supports RGB scaling via X video. -Mike M. ]

Vadim P. wrote:
-----
I suggest Adobe quickly figure out a way to get GPU acceleration working with Compiz. What's the point of adding features that a quickly shrinking percentage of Linux users can make use of? Do you think many Vista users would disable Aero just to make use of features in a browser plugin? Sheesh!!!
-----

Why don't you do some more investigating before blaming Adobe for the fact that ANY windowed OpenGL-app will most likely suck (e.g. flicker and what-not) in a composited environment (Compiz) because of limitations in the current Xorg/AIGLX architecture and Linux graphics drivers. Adobe didn't design AIGLX, now, did they ? Nvidia may have work-arounds for these problems in their proprietary Linux-driver, but not everyone has Nvidia-cards. The work towards solving this fundamental problem in the X-server seems to be progressing nicely (e.g. DRI2), but it's not generally available, yet.

Some links:
http://www.phoronix.com/forums/showthread.php?t=7889
http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html
http://hoegsberg.blogspot.com/2008/03/i-just-committed-last-bit-of-dri2-work.html
https://wiki.ubuntu.com/RedirectedDirectRendering
http://dri.freedesktop.org/wiki/DirectRenderingToRedirectedWindows

"do something about the crashes and apparent pulseaudio conflicts"

To be fair, I imagine the flash player uses ALSA and/or OSS.. the two standard audio APIs on Linux and other Unices respectively. PulseAudio's ALSA plugin is quite buggy, yet certain distros insisted on making it the default anyway, despite several known problems. I'd recommend complaining to your package manager and disabling PulseAudio until its issues are resolved (unless you're doing networked sound, you won't lose much, if anything; might even gain depending on your hardware).

"it's the ensuing glXDestroyContext() that crashes. -Mike M."

Again, calling stuff like this is rather standard behavior for detecting accelerated GL in X. As long as you're doing it properly, I'd wager to bet it's a rather buggy driver and not an issue for most people. Of course, without being able to peer-review the code, it's difficult to say what the problem really is.

Sorry, my earlier reply quoted the wrong name (Vadim P), please excuse me, I'm blind (ok, not really blind, just not looking closely enough :). It was meant as a reply to a post by Anonymous.

Regarding the OpenGL detection crashing, I have seen Wine itself crash over a VNC connection when detecting OpenGL, thus making it unusable. I would suggest forking off a new process, setting a new SEGV handler with sigaction(), and running the check there. If it crashes, tell the original process that GL isn't available.

[ Hmm, that's just crazy enough to work... -Mike M. ]

I can understand the preference for stability over performance.

However, would it be possible to have some flash-config file (.config/adobeflash) or something where can overrule these detected settings?

This way, the more technically inclined can tweak it to their liking. You would also get valuable feedback on certain settings.

I would also suggest to use this to allow us to set an audio-output. On most mainstreams distrobutions pulseaudio is going to be the future.

The do-it-yourself types could use the same config file to tell it to use alsa or oss.

Again: I can understand the preference for defaults that make it crash the least often, but in the linux world, being able to tweak and make those choices for ourselves is what we expect and one of the reasons why we chose linux.

Therefor i pledge for a flash config file, where we can overwrite the soundoutput and wether or not it should use acceleration.

Another added bonus is they the compiz developpers would be able to experiment and see _why_ compiz and flash do not mix; perhaps fix it at their end?

Thanks for your time!

"I would suggest forking off a new process, setting a new SEGV handler with sigaction(), and running the check there. If it crashes, tell the original process that GL isn't available."

I would be careful with that. It's not unusual for systems to be configured to automatically create a core dump when an app sigsegv's. And if a regularly-run app were to silently spawn a child that crashes, it would end up leaving a mess in the unsuspecting user's home directory.

If the problem happens in a non-local X server, shouldn't it be possible to detect that and assume no GL (with a config option to force the check anyway, just in case; eg. ForceGLCheck=enable/disable)? Another config option could be made available to force enable/disable GL in case it detects wrongly, in either case (eg. ForceGL=enable/disable/autodetect).

Thanks for noticing that native 64-bit is a much clamored-for feature

>>Thanks for noticing that native 64-bit is a much clamored-for feature

Ditto.

And glad to know he's paying attention the comments :)

2Chris: even if the system is configured to create coredumps, there are a lot of workarounds for this. Just make setrlimit(2) call, setting RLIMIT_CORE to 0 - and that's it, no more coredumps for this process. Also you can simply intercept SIGSEGV by defining corresponding sigaction(2) and properly returning exit code. Just don't you dare to do this from main flash process (browser thread), it might work, but isn't safe, since you can't really predict what exactly happens with your data when you get SIGSEGV.

On the matter: geez, I just can't imagine WHY adobe even thinks about such worthless stuff when highly critical issue of supporting 64-bit platforms remains! Can't they understand that flash is the last piece of proprietary software that holds off pure 64-bit desktop platforms in a lot of cases? We have to use 32-bit browser for years already, since flash under nspluginwrapper tends to crash and swfdec isn't advanced enough. Living without wmode support is quite annoying, too...

"I would be careful with that. It's not unusual for systems to be configured to automatically create a core dump when an app sigsegv's. And if a regularly-run app were to silently spawn a child that crashes, it would end up leaving a mess in the unsuspecting user's home directory."
it shouldn't create a coredump if the signal is caught.

I tested on youtube video with Compiz on and off and noticed no significant difference.

I checked glxinfo and I matched everything except for these:
# GL_ARB_shader_objects
# GL_ARB_shading_language_100
# GL_ARB_fragment_shader

But when I load up the nvidia-settings tool and go over to the OpenGL/GLX Information it lists everything. Does this mean there is a problem with glxinfo or is there a better way to detect for these needed extensions?

"And converting back to YUV space after compositing, so that scaling can use hw acceleration - is that difficult concept to come up with? Jesus..."

But why would you want to do that? Converting back to YUV again incurs quality loss and more CPU time

The Radeon R100 supports 4 RGB Xv image formats, so it does exist in the wild.

Number of image formats: 8
id: 0x41424752 (RGBA)
guid: 52474241-0000-0010-8000-00aa00389b71
bits per pixel: 32
number of planes: 1
type: RGB (packed)
depth: 32
red, green, blue masks: 0xff0000, 0xff00, 0xff
id: 0x54424752 (RGBT)
guid: 52474254-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: RGB (packed)
depth: 16
red, green, blue masks: 0x7c00, 0x3e0, 0x1f
id: 0x32424752 (RGB2)
guid: 52474200-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: RGB (packed)
depth: 16
red, green, blue masks: 0xf800, 0x7e0, 0x1f
id: 0x0
guid: 52474200-0000-0010-8000-00aa00389b71
bits per pixel: 24
number of planes: 1
type: RGB (packed)
depth: 24
red, green, blue masks: 0xff0000, 0xff00, 0xff
-- snip --

muy interesante

Come on! compiz/kde4 effects or flash? Do I need to choose? This sucks... I hope a free and opensource alternative arrives soon, Adobe sucks

Nice blog entry!

I have a Thinkpad T21 (ProSavage IIX) which has the SGI stuff in glxinfo. It's good enough to play things like TuxRacer, etc.... but explains why my desktop (nVidia 6600 GT) plays Flash video **so** much more efficiently, even given it's much beefier hardware. Even so CPU use is still far higher than I'd like on my desktop, but it was great to see marked improvement in Flash for Linux via 10 BETA.

Could you please make a post regarding the status of WMODE and amd64 support?

Could you tell the community how they can help to resolve these issues, if you don't have the bandwidth?

If you don't have the bandwidth, could you tell us why?

It's not like there are people mentioning WMODE on every single penguin.swf blog post because they simply want to annoy you. There simply isn't much in the way of feedback coming from penguin.swf regarding these insanely high priorities that's been outstanding for years.

[ There are more accurate solutions, and we tried to use them; unfortunately, they crashed on certain software drivers on several different Linux distributions. -Mike M. ]

Thanks for your efforts and the useful information about your difficulties with the hardware acceleration.

Evidently you are finding it difficult to come up with a scheme to detect and use hardware acceleration that works on many driver-distribution scenarios. Time-honored principles in such a situation suggest that try with something
simple first. Assume one or two
commonly used driver-distribution scenario. Make it work. State the assumptions clearly. Then it will be a lot more clear why it doesn't work with other cases.
There are many knowledgeable people here in this blog who can and want to help you figure out how to make other scenarios work. At the very least you can tell us details about one system scenario where you made it work. That will help us know at least one way to get smooth fullscreen working as a last resort.

Arun

I don't understand the GL feature requirements for accelerated rendering. I have a pretty powerful graphics card but I'm missing two of the features. That means that while the amateur hobbyist totem movie player can play fullscreen flv videos using almost no CPU, and never skipping a frame, the "commercial quality" Adobe flash player plays an unwatchable slideshow. I don't understand why adobe can't make their software work properly when a smelly besandled nerd can.

I do understand it must be very hard for a big company like adobe to create working code. I mean, if you attain all your products by buying up companies, it must be very hard to understand all that alien code. And I won't ask for open-source flash from adobe, i know better. I do think adobe must clean up their act, or face the open-source consequences.
Flash used to work on my m7000 armada (700mhz) and fullscreen too! Now my 3.7GHz system is just barely enough to play flash fullscreen!
I do not think proprietary flash will be longlived if this situation continues.
Hasta la victoria siempre! ;)

What about a FreeBSD port of the player?

Adobe already supports Linux, Mac and Solaris, all UNIX-compatible, and the later two making use of the X11 subsystem and OpenGL, just like FreeBSD.

FreeBSD already have support for proprietary technologies, distributed as binaries, like nVidia drivers. Also, FreeBSD does have a comprehensible release schedule, with well documented APIs. I wonder why Adobe doesn't support this platform yet.

There are any plans? I would like to receive Adobe news regarding this issue in my email. Thanks Mike Melanson!

Dear Adobe, see it this way, people are using flash on 64 bit systems using npviewer.bin, this thing hogs a lot of computer.

a lot of CPU power mean a lot of energy lost

do something, it's really embarrassing that in 4+ years it's still impossible to use it natively

Is there actually a *working* setup?

I have troubles with fullscreen playback as well on an ATI RS960 Radeon X1200 Series (embedded in motherboard) with the distro's radeon driver. I've only had successful fullscreen playback with my i810 intel driver (82945G/GZ), but I don't seem to have anti-aliasing (I don't think its supported by the chip).

If there is a Adobe Flash Player for linux with hardware acceleration support, I expect the Adobe devs have seen the results... Are there any Adobe hardware recommandations for a full linux user experience?

What hardware/drivers/setup have you guys been working on to have fullscreen, smooth and anti-aliased Flash 9 r115/124? Have you tweaked the drivers? Which? How?

Thanks.

Regards,
Alex Conrad

Ok, i know this is closed source, but u noticed that one of the most requested feaures is 64bits support.
why not to make a site where we can help voting the next...FIX... or feature??? is some way to give ppl what they want!
most of us are not asking for bells and whistles only 64 bits support, wmode....

thanks!

Luis,

Sign up for adobe's issue tracker, and vote.

http://bugs.adobe.com/jira/secure/BrowseProject.jspa

Testing Astro Beta with KDE 4.0.82 (KDE 4.1 beta 2)

As you may know, KDE 4.0.82 features KWin 4 as its windows manager, and KWin 4 is capable of doing the exact same set of screen animations that Compiz does. The experience with Astro here is awesome. I'm getting fullscreen antialiased video here, at speeds I've never seen before, and, from what I'm looking at (CPU usage for Flash Player / X.Org) Astro is using hardware acceleration here, despite the fact I'm running KWin with AIGLX, eye candy and all the bells and whistles.

I'm thinking that the source of the bug between Astro and Compiz may be closer to Compiz and farther to Astro. Please, if you can, work with Compiz programmers and help them. And, don't disable HW acceleration for Compiz, please ;)

Nice work - I'll waiting for next time.

I think it's really funny how Adobe tries to implement shiny new features on a player that has many old simple bugs. I don't care about the latest flashy features. I do care, however, about wmode/transparent for linux (and solaris, BSD, all the flash versions). I also care about 64-bit support. I think you know that adobe (with acrobat reader and flash player) and SUN Microsystems (with java) are the two companies that are holding 32-bits architectures alive. Yes, it's that way. I think many people would use 64-bit only if there was a 64-bit acreobat reader, a 64-bit flash player and a 64-bit java plugin. Think about it, all the new features are just to disguise adobe's lack of interest in fixing the old bugs (which in the end is what we, the users, need).

Regards.

So, you're working on features that are not even in the top-3 most wanted (these are: 64-bit, wmode/transparency, and V4L2). How's that for listening to users?

64 Bits, and Wmode/transparency are always missing/buggy.

Do something for !

I cannot believe flash is still using RGB as its native format for video. This made sense for flash animation. But now, that flash is the main player for online video and using H264 as main codec, what a waste of ressources to do this extra RGB conversion and not take advantage of YUV hardware support:-(

[ Read the post again. -Mike M. ]

Is there any chance you can open the source for the bits that are giving you a hard time? You have opened the source for tamarine, and something to do with the audio system already (if I remember correctly), why not open the bits that deal with rendering (like what this post is about) and that deal with WMode. There seem to be plenty of knowledgeable people that would be willing to help, and that kind of access to at least some of the code could help individual distros get flash working on their individual platforms.

Is there a linux command or script that we can run that will show if the v4l2 device will show up in the flash player. We are working on a new capture card and device driver for linux and would like to support Flash.

Thank you for your efforts in bringing an updated Flash Player to Linux.

However, there are two things I don't believe:

1. Grepping glxinfo for "Direct rendering: Yes" causes crashes when grepping glxinfo for "SGI" doesn't crash.

2. GPU acceleration can't work in a window when Compiz is running. I *must* be misunderstanding what you're saying, because everyone has played Return To Castle Wolfenstein in a window with Compiz running. Well, maybe not everyone, but I certainly have.

I'd also like to point out that Compiz doesn't just come preinstalled - it even starts automatically in most distributions these days.

Good work so far though, and lots of luck.

http://www.intel.com/
Doesn't look as it should for me.
I see the intel logo and some times i see the choose country for 1/10 of a second, then i see the "loading bar".
Then it's white with only logo and foot of the page.
If i turn of flash it works as it should.
Firefox3.0

[ Reproduced. Fixed locally and will be included in the final release. Thanks. -Mike M. ]

FYI, I have installed the latest ATI drivers (from their website) and the "client glx vendor string" is still SGI. I've tried all the ATI drivers I could find (open source, binaries packaged by the distro, binaries from ATI's website) and I still get the damn "SGI".

I have opened a ticket on Ubuntu's bug tracking:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792

As you will read, I wanted to hack glxinfo so it would return a dummy string, but I suspect that flash is not grepping glxinfo's output.

I don't really know if that workaround should be done by ATI or the glx guys (mesa?).

Anyway, I have sent a mail to ATI's linux driver team to know if they can fill up the data correctly so Flash Player can have fullscreen hardware acceleration enabled.

NVIDIA users seem to have something besides SGI, which should work for them if they use the proprietary drivers.

I really, *REALLY* need that fullscreen working on my linux box (Xubuntu Hardy) with the RS690 X1250 chipset. It's a shame that the hardware detection is so poor. Wouldn't "Open GL vendor string: ATI Technologies Inc." at least been a better detection mechanism?

I really hope there will be a Flash 9 update release with that fix *soon*.

Thanks for the effort.

I've had talked with the Mesa developers.

There are saying that "client glx vendor string" is the name of the author of the GLX layer. SGI is shown here as Silicon Graphics played an important role
in OpenGL standardization. Plus, they explained me that NVIDIA provides their own GLX layer and this is why it says NVIDIA. Everyone else uses the GLX initially made by SGI.

Thus making it obvious that Adobe didn't even try Flash Player for linux running with an ATI card and the fglrx drivers. Nor any other card than NVIDIA ones.

Here's the thread of what has been exchanged regarding that client glx vendor string:

http://sourceforge.net/mailarchive/forum.php?forum_name=mesa3d-dev&max_rows=25&style=ultimate&viewmonth=200807&viewday=25

Any upcoming Flash Player 9.0 release? I think a bugfix release could be done. Mean while, I'll try hacking the GLX to have the string changed. I need that fullscreen working *badly*.

HTH.

Regards,
Alex Conrad

Howdy, me again. Sorry to comment on an old post, but...

Are you using OpenGL code ported from the Windows version, or is it all handwritten? If the latter, it may be worthwhile to ask the X.org developers to add the RGB colorspace to their Xv implementations. At least one driver (nouveau) supports it, and I'm prepared to patch radeon to support it as well. The Intel drivers can also support it in HW, thanks to textured video, so patches could be written for them, too.

~ C.

As one of Intel's representatives to the OpenGL ARB, I'm appalled by this horrible misuse of the the GLX client string. The GLX client string conveys no information about the existence or quality hardware based rendering. It is intended for debugging purposes, and using it for anything other than that is completely and undeniably wrong.

Please fix this bug.

[ It is also the most reliable detection method we have found (that doesn't crash on multiple problematic platforms). -Mike M. ]

If you find an interface that should work but crashes, please submit a bug. Do not rely on using interfaces in unintended or undocumented ways. I know that's the standard way of doing things on Windows. We actually fix our bugs when we know about them, so you don't have to do that here. Really.

I think the fact that this "most reliable detection method" is reliable only on Nvidia's closed-source driver is pretty clear evidence that it's not at all reliable.

The only semi-reliable thing to do here is to use the GL_RENDERER string. On the software-based indirect methods this is "Software Rasterizer" on recent versions of X. On older versions I think the renderer string would have just been "Mesa".

Even this isn't really the right way to do it. The right way is to either let the user pick or at installation time compare the performance of the GL path and the non-GL. Pick the one that's better. It is entirely possible that your software may beat older hardware. It is also entirely possible that a "software" GL version could beat your software. Stranger things have happened.

Hello.
Maybe I'm asking a stupid question, since I'm not a programmer or a graphics/xserver expert, either.
Why can't we use a system that works using compiz's zoom features? When I want to watch a youtube video in full screen I don't use flash internal full screen functions, but I zoom it using a compiz default plugin ("Zoom desktop"); by using this method I'm able to zoom to the flash video frame and watch any fullscreen clip without choppy framerates. So, the question is: isn't there a way to use another "kind" of fullscreen that interacts with compiz, once it is detected by flashplayer?

Regards,
Maurizio

For your information, I never could make the FP9 9.0.115 (and 9.0.124) with a smooth fullscreen playback with:

- ATI Radeon X1250: antialiased with the propritary drivers downloaded from ATI.com but slow fullscreen. I may have tweaked (or not) the settings throught the ATI GUI settings (using the "amdccle" command provided by the drivers). I fill all the GL_* requirements, but have "SGI" set as the "client glx vendor string".

- intel i845: fullscreen playback is okay, but not antialiased (fonts are ugly). Here I don't fill all the GL_* requirements. I guess I'm fully running software rendering. I also have SGI set as the client vendor string.

In both cases, I had much screen tearing.
http://en.wikipedia.org/wiki/Page_tearing
http://hifi-india.blogspot.com/2006/11/faq-what-is-screen-tearing-and-how-do-i.html

Although, I just got a new box with a NVIDIA GeForce 7025 chip (motherboard integrated) and I was finally able to make Flash Player 9 for linux run correctly. I made it work with the Envy drivers provided by the ubuntu distro (downloading drivers from the NVIDIA site has not been tested, but I suspect that's how Envy does it). After a reboot, it works out of the box. I do get fonts antialiased and the playback is smooth. Plus, I don't seem to have any screen tearing effects anymore (or maybe less visible). I do have all the GL_* requirements and client vendor string is something besides "SGI" (see why from one of my above posts).

I hope this feedback helps.

Regards,
Alexandre Conrad