WebPlayer having a ReadPixels problem in a specific web browser

I’ve got a unity web project I’m finishing up shortly and there’s a screen grab at the end of each session that we save out. It works great most of the time, but as luck would have it, the browser that one of our clients uses doesn’t do it right. Here’s the user agent string (the reason I’m targeting the user agent string is because the webplayer version and platform are identical to other ones that work just fine, so it seems to be browser specific).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB6.6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

I’m capturing a section of the screen, using an offset of X,Y and a size of W,H. In most cases, these work as expected. It starts in the bottom left corner, goes over X and up Y, then starts there to do the screen grab of W across and H up. On this offending agent, the X and W come through okay, but the Y and H are somehow not correct. It seems to actually go up only half of the Y value, and then capture H pixels DOWN instead of up (in my case, wrapping back around to the top of the texture).

Here’s the code (also, the width and height of my player is 720x600)

yield return new WaitForEndOfFrame();

Texture2D tex = new Texture2D( 320, 180, TextureFormat.RGB24, false );
tex.ReadPixels( new Rect(200, 180, 320, 180), 0, 0 );
tex.Apply();

byte[] png  = tex.EncodeToPNG();
Destroy( tex );

I later upload the png to my webserver, etc…

I can maybe throw a demo scene together at some point, but for now I just wanted to make a record of this in case somebody else runs in to this as well - or see if maybe somebody has some advice. I plan to essentially hack it with a yOffset when the user is using that agent, but that could be problematic if this bug someday gets fixed.

Is there any reason to suspect some other cause to this problem other than the browser? Like I said, the Application.platform and Application.unityVersion are identical to others that work perfectly. All images uploaded with this user agent are broken.

Again, for future reference, I’m going to follow this up with later findings. Since we didn’t have a machine in house with a matching browser string, we hunted down an XP machine (which is what Windows NT 5.1 is) and installed Internet Explorer 8. Unfortunately (or fortunately, depending on how you view it), this machine worked fine. On closer examination of the browser string, you can see it doesn’t actually match:

NEW WORKING BROWSER:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)

BROKEN BROWSER:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; GTB6.6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

It appears as if that string somehow tracks the .NET add-ons, etc. So somewhere in those strings is a clue as to why it is broken. But I don’t really have time (or machines to mess with) to find the actual bug. I’m just hacking a fix together instead. Basically, when the trouble string is detected, I capture a different screen rect. Here’s the numbers that work:

tex.ReadPixels( new Rect(200, 411, 320, 180), 0, 0 );

It makes no sense, but it fixes the problem (for now).

did you check screen color depth?
sounds like the failing machine might plain simply be running in 16bit depth thus making a 24bit read fail completely.

I don’t have direct access to their machine. It’s a client of a client, so figuring this out remotely has been fun.

It seems weird that the read works, but that it’s off by 231 pixels and “reading” down instead of up. If it were failing completely, would it read anything?

Hey guys ,
Same kind of bug here!
Read pixels work as expected when given an area to read from the screen in most browsers except Safari on macs.

Any idea why that is happening?

Would be nice to know, lose an entire morning trying to figure it out till read your message, since in my case the users dont have mac I thing is fine for now, but its annoying.

This problem is wider than thought, I’m finding ReadPixel reads one way on a PC and another on iPad and Android