Incorrect rendering on Safari 6 about jsc3d

[GoogleCodeExporter]

Wireframe mode looks correct, so it is probably a problem with the rendering of 
textures, not the geometry itself.

Original comment by [email protected] on 29 Sep 2012 at 2:35

[GoogleCodeExporter]

That sounds really stange. I took a look into this document 
http://www.phoboslab.org/log/2012/09/drawing-pixels-is-hard. It indicates that 
the latest implementation of Safari automatically scales a loaded image to fit 
the size of the back storage buffer. Thus before grabbing pixels of an image 
through the canvas api, we need to multiply/divide a ratio factor to get the 
correct dimentions in advance.
Jsc3d's texture generation does utilize an internal canvas. That new feature 
would definitely deface the textures.
Unfortunately, I cannot find a Mac device with Safari 6 to reproduce the issue. 
Could you upload some screenshots here thus I can have a vision of this 
problem? Or you can send to my gmail if the pictures are large :-)

Original comment by [email protected] on 8 Oct 2012 at 2:18

[GoogleCodeExporter]

Thanks for investigating this! Attached is a screenshot.

Original comment by [email protected] on 8 Oct 2012 at 2:29

Attachments:

• jsc3d_safari6.png

[GoogleCodeExporter]

Thanks, Bgsawyer! The rendering just looks like Minecraft style.
I made a slightly modified version that uses webkitPutImageDataHD() instead of 
putImageData() whenever available, and also a simple demo to test it. They are 
in the attachment. Could you test to see whether it generates correct result?

Original comment by [email protected] on 9 Oct 2012 at 9:43

Attachments:

• jsc-safari6.zip

[GoogleCodeExporter]

Screenshot attached. Same result, unfortunately. :( But I appreciate you 
trying, and I'm happy to keep testing revised versions if it helps you to get 
it working.

Original comment by [email protected] on 9 Oct 2012 at 1:48

Attachments:

• jsc3d_safari6_test1.png

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It seems as if jsc3d's scanline rasterizer goes wrong way. I suspect Safari's 
new javascript engine modified some floating point calculation principle. I'll 
look for a Mac device to debug into it.

Original comment by [email protected] on 10 Oct 2012 at 9:36

[GoogleCodeExporter]

I am facing the same issue with all my macs with all modern safari browsers! Is 
there any possible solution to this? I would be very interested in having any 
suggestion how to resolve this.

Original comment by [email protected] on 23 Apr 2013 at 5:54

[GoogleCodeExporter]

I had the same issue and after a few hours of investigations I found that the 
problem is related to floating point calculations on Safari's javascript engine.

i don't have any knowledge about the safari's javascript engine, but after I 
added this line in the rendering loop all is working fine.

~~(null * 255);

Probably this will trigger something into the javascript engine and the issue 
just gone.
 (I'll be back tomorrow with some code after I'll refine the solution a bit)

Original comment by [email protected] on 11 Jul 2013 at 7:09

[GoogleCodeExporter]

Finally I've found that it's enough to have this call in the rendering method:

var patchForMacSafari = 1*null;

in fact it's required to have null*<something>; it seems strange to me but it's 
working. please let me know your opinions about the reason. (or maybe a more 
professional solution)

this is how my rendering method looks now:

JSC3D.Viewer.prototype.renderSolidFlat = function(mesh) {

   var macSafariPatch = 1*null;

    var w = this.frameWidth;
.
.
.
}
and now the flat rendering is working nice on safari for mac.

Original comment by [email protected] on 12 Jul 2013 at 7:33

[GoogleCodeExporter]

It's so kind of you to put help on this issue which bothered me for a long 
time! 

How does the new variable macSafariPatch be used in the source and is there any 
document or discussion on the floating point issue of Safari's js engine?

Original comment by [email protected] on 13 Jul 2013 at 1:44

[GoogleCodeExporter]

Hello,
 This new variable will not be used anywhere in the code; the javascript engine just needs to execute this strange operation.  (null*<something>)

practically there is not needed to store the result into a variable the 
rendering will for example if you just write:

JSC3D.Viewer.prototype.renderSolidFlat = function(mesh) {

   1*null;

    var w = this.frameWidth;
...

I know is strange.. but this solved the issue. 

That's why I'm thinking this is a javascript engine issue. (because this 
variable will never be used.. but the engine will work after this operation is 
executed)

(More that this... the rendering is working fine without this operation if the 
debugger console is opened. )

I didn't find any link on forums or official documentation about this issue. i 
just discovered during debugging by isolating the issue step by step. 

(is true that I didn't spent time finding an official discution about it)

Original comment by [email protected] on 13 Jul 2013 at 6:10

[GoogleCodeExporter]

Hi, Vasile:

I haven't got a mac device at hand to prove it. Could you test to see whether 
it helps all render mode to work correctly? And is it also ok if I move that 
line (1*null;) to viewer.init() or the constructor and call it once at the 
beginning?

This demo http://jsc3d.googlecode.com/svn/trunk/jsc3d/demos/test.html is 
convenient for the test. It can also be found in the 0.9.7 download package.

Original comment by [email protected] on 14 Jul 2013 at 1:42

[GoogleCodeExporter]

Hi,
I don't have a Apple device at home in ordere to test again now but it was 
tested in all rendering modes by our QA department at office and they said is 
working well.

So it's safe to commit it.

Original comment by [email protected] on 14 Jul 2013 at 7:21

[GoogleCodeExporter]

Shall I put this '1*null;' in viewer's initialization code or one for each 
renderXXX()?

Original comment by [email protected] on 14 Jul 2013 at 12:08

[GoogleCodeExporter]

In each rendering method I tried to put in init or even upper into my 
application code but it's not working ; it has to be in each rendering method 
probably because there is an execution context for each method. 

Original comment by [email protected] on 14 Jul 2013 at 2:46

[GoogleCodeExporter]

I see. Many thanks Vasile!

Original comment by [email protected] on 14 Jul 2013 at 3:46