Or ... "When to call pluginWindowMac::InvalidateWindow()"?
Apologies. It's hard to be brief here, it's a fairly specific test case.
I'm testing an NPAPI plugin (now adapted to Firebreath) under Firefox,Safari,Chrome and IE.
I'm testing the plugin under both Windows and OS X.
It's a video player using OpenGL for all rendering. So on OS X I'm using a CAOpenGLLayer
derived class, and supporting the Invalidating Core Animation model, which is used under
both Firefox and Chrome.
The plugin is running well in all cases and on both platforms, except for Chrome (v26.0.1410.65) on OS X, where I'm seeing a weird 'refresh' issue under both OS X 10.6
and 10.7.
It's as if Chrome is double-buffering the composited layer somewhere. It's always one
'frame' behind the one drawn via OpenGL. I've proved this by numbering each draw call
and drawing that number into the OpenGL render as well as logging it via NSLog. What's
on screen is always one behind the logged draw callback (I'm not rendering video at
this point - it's paused).
By using a specific keyboard event to trigger a extra call to pluginWindowMac::InvalidateWindow(),
I can force an external invalidate that will bring what's on screen into sync with
what was last rendered, but it will lose sync again on the next draw call (triggered
by the layer setNeedsDisplay).
I'm presently calling pluginWindowMac::InvalidateWindow() at the end of each draw
callback. In other words at the end of the layer 'drawInCGLContext()' call. This would
seem to be the only logical place to do it. But I'm beginning to suspect that under
Chrome this just isn't working? Clearly the call works - as proved by the keyboard
triggered InvalidateWindow, but maybe it doesn't work from inside drawInCGLContext?
The plugin is running fine under Firefox (the other browser that uses Invalidating
Core Animation). But maybe that simply doesn't rely on a working pluginWindowMac::InvalidateWindow()?
Has anyone else tripped over this issue with Chrome? Any workarounds discovered? About
all I can think of right now is some kind of timer driven event to trigger an extra
Invalidate.
Related
How it is reproduced:
I go to the page where the viewer is used. Let's say, while waiting for it to fully load (it doesn't matter), there is no error in the console. Next, I go to another page on the site where the viewer is used.
When I load the page, an error appears in the console(attach a screenshot). After that, if I try to draw the model in the viewer, the viewer does not draw the model completely. And the viewer does not allow you to work with elements (for example, selection).
As a result of what could this error appear?
I didn't do anything special with the initialization of the viewer
Viewer verssion - 7.65
It is definitely possible to run the viewer in multiple browsers/tabs at the same time. Each tab should be using its own GPU context. I just tried loading the following URLs in different browsers at the same time, and all the viewers are rendering the models correctly:
https://forge-basic-app.herokuapp.com/#dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Zm9yZ2UtYmFzaWMtYXBwLWJ1Y2tldC9yYWNfYWR2YW5jZWRfc2FtcGxlX3Byb2plY3QucnZ0
https://forge-basic-app.herokuapp.com/#dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Zm9yZ2UtYmFzaWMtYXBwLWJ1Y2tldC9TcG9ydHMlMjBDYXIuZHdmeA
Are you seeing this issue with any Forge app (like the one I linked to), or just with your own one? And have you tried other browsers and other devices? It could also be hardware-related. Perhaps your hardware has fewer resources, and when one of the browser tabs loses context, the viewer cannot recover from that?
Using Surface pro touch screen to select element in viewer works sometimes other times it seems to translate to a rotate/zoom action. In this case the viewer rotates/moves and the element is NOT selected.
When logging the events there are plenty of mouse down/up events along with mouse moves when it doesnt work. When select does work a single click event occurs.
Double click seems to work ok.
Zoom/rotate etc using standard tools works ok.
Using the keyboard cover touch pad that you can get for the Surface pro to move and click works as expected and the element is selected.
Running same application on a GETAC Windows 10 ruggadised tablet the select element works correctly so it seems related to the Surface Pro.
Unable to change browsers as cordova apps use IE11 on windows and that is currently fixed.
The only solution i can think of for the moment is to remove the standard navigation tools completely (somehow) and recreate a select mode tool that would ignore any mouse moves and use button down event to select element.
Any suggestions on how to fix this?
Tech Details:
Windows 10 Pro,
Surface Pro,
Browser: IE11,
Viewer version 2.11,
Other: WINJS81 cordova application
Thanks for any help
We've had problems with touch events on the Surface Pro in the past. It sounds like the edges of the touch screen are overly sensitive and are triggering extra touch points.
Does the problem happen if you are holding the device up, gripping with one hand, and using your other hand to touch/select a 3D object ?
Could you try doing a selection again, but this time, make sure you other hand is not holding the edge of the screen? (Perhaps place the device on the surface of a desk, so you are not holding it up)
Found a fix to this issue. In viewer3D in the base toolcontroller there is line
var kClickThreshold = 2;
This value is used further down in code to determine if singleClick has occured. It does it by comparing XY on down and up events.
var deltaX = _downX - event.canvasX;
var deltaY = _downY - event.canvasY;
_downX = -1;
_downY = -1;
if( Math.abs(deltaX) <= kClickThreshold && Math.abs(deltaY) <= kClickThreshold )
_this.handleSingleClick( event );
If movement is above this threshold it does not trigger singleClick if below it does.
Did testing and increasing the value to around 5-7 means that the selection of elements worked consistently. (there is still a minor rotate or zoom at same time as select occurs but I assume that this would be another part of viewer that would need adjusting)
Unfortunately it does require edit of viewer code but easy enough. I added code to overwrite standard value if external variable existed.
Would be nice for future viewer dev if more of these types of properties be exposed so that direct edit of code is not required.
Still it is good to have the source code to be able to debug at this level.
At a guess the Surface Pro 4 must have a more sensitive touch system or it could just be related to IE11 as well.
I am using Vimeo's Flash API so that I can embed and read the timecode of a video using the playProgressHandler, pause it at certain times, pop a menu, and use buttons that trigger seekTo calls. Although everything works, the timecode is inaccurate to varying degrees. Anywhere from 1-2 seconds. I can tell this because:
1) If I play my video on Vimeo and pause it at 6:03 and do the same with it embedded in Flash the visuals do not match up. Flash is lagging behind a tad.
2) I did a test using the JavaScript API. My seekTo calls were consistently accurate. To seek to the same spot using the AS3 API I had to add 1.5 seconds. But even this isn't foolproof. Sometimes it works, but sometimes it's still off.
Any ideas what would account for this inaccuracy and how I might fix this problem? Yes, I can ditch the AS3 and use the JS version, but I'd prefer to just fix what I've already built.
(I also posted this on Vimeo's forum, but I'm following their "Limited support in API Forum" post which suggests to post here)
Unfortunately, there's not much we can do to fix this other than to recommend that you use our iframe embed.
It has to do with the way that we retrieve files from our CDN. Because Flash doesn't support byterange requests, we pass a parameter that returns part of the file starting at that position. The nature of how that works means it's always going to be imprecise.
I have created a Polymer application that is listening for the trackstart, track and trackend events. It uses these events allow a SVG element to be dragged around. The events work correctly for desktop, however, for my Galaxy Nexus and Nexus 10 the events are not fired.
I have looked at the source code in the polymer-gestures project and it seems like the events are implemented using the touchstart, etc events in touch.js.
I'm using version 0.3.1 of platform.js which I assume has the polymer-gestures 0.3.1 in it.
How can I get the trackstart, track and trackend (also hold would be nice too) events working on my touchscreen devices?
So it'll be the touch-action:none CSS value that is needed to make sure the events are handled with JavaScript.
Creating an application that requires BOTH gesture(swipe) support as well as simple touch events. I understand that one limiation of the built-in touch support in actionscript is that you must choose either Gesture OR Touch events as input.
So I was wondering if you can easily simulate gesture events using the TouchEvent.TOUCH_BEGIN +TouchEvent.TOUCH_END events? Are they essentially the same thing as using Gesture events?
I believe you'll be able to simulate the gestures appropriately by using the touch events. Each time a finger goes down a temporary id is assigned to it so you can easily tell if this is the first or second finger down. In terms of them being the same, it's not exactly the same since the GestureEvents seem to be all dependent on the mobile OS to report as gestures instead of just as touches so any calculation for deltas (or whatever else) would be handled by the OS already instead of you doing it (with the overhead of the VM). http://help.adobe.com/en_US/as3/dev/WS1ca064e08d7aa93023c59dfc1257b16a3d6-7ffd.html
Try making gestureevents with touchevents. There are lots of properties that can easily be converted / combined.