1 Follower

About botmaster

Recent Profile Visitors

I work with Typescript and I simply have a base class that allows dragging with: startDragging(rect:Rectangle, center:boolean) and stopDragging(). Doing that kind of stuff with Typescript is easy, with javascript it's more tricky.

Your problem would be the same with any other technology, Sprite2D, Flash, etc ... Would slow down the exact same way. You cannot just keep on drawing new objects (triangle) constantly, it's too much work for the CPU or the GPU or both. The solution > You need to cache. The basic idea: Draw what's NEW with a graphic but draw what's already DRAWN in a texture, you end up with a texture with everything that has already been drawn (a piece of cake for GPU to render) and a graphic with only the latest stokes (expensive but manageable by GPU). When user draws again render your texture (draw cache) with everything the user has done, empty your graphic and start drawing again with it, etc ....

This is a situation where the more you try to do at runtime, the slower and more memory consuming your app is gonna be. Personally I would focus on asset preparation where countries are defined by a series of points (json probably) and all countries map/details are extracted as individual assets. At runtime I display only the interaction layer, as the mouse hovers the map I check if mouse coordinates are inside a defined country area (there's a formula to check if a point (the mouse) is inside a series of point) and if it is I display the corresponding country view at the right location, if clicked I display the country detail view, etc ... More asset preparation but a very fast and responsive app at the end.

Not familiar with PIXI sound library but the WebAudio API does allow seek so if PIXI sound doesn't expose that type of method you should be able to tweak it to do it. The WebAudio API is really one of the best I've seen in years in any technology. There's isn't much you cannot do with it.

In typescript it's a breeze, we really have no problem with this. With webpack you just need to make sure the pixijs is included in your vendors and loaded before your app and you'll get no problem at runtime. For tlint it's all about getting the correct @types/pixijs, you can create fake ones if you need to.
Also notice how a "Sprite.fromImage" really works under the hood, it's calling the texture.fromImage so you can simply extend Sprite and pass a texture in constructor and really any other system:
Sprite.fromImage = function fromImage(imageId, crossorigin, scaleMode) {
return new Sprite(_Texture2.default.fromImage(imageId, crossorigin, scaleMode));
};

Here's a simple explanation:
All GPU drawing use the painting algorithm, it draws everything from bottom to top on top of each other.
Let's say you draw 20 layers on top of each other and all those layer require the SAME program/shader then you end up drawing everything in: 1 DRAW CALL
Let's say you draw 20 layers on top of each other and each layer use a different program/shader then you end up with: 20 DRAW CALLS
1 DRAW CALL is way better than 20 DRAW CALLS, simple right?
Now let's say you draw 20 layers and you have 10 layers requiring one program/shader (let's call them shader 1) and the 10 other layers requiring another program/shader (let's call them shader 2), how many draw calls do you get?
If you draw a shader 1 then a shader 2 then a shader 1 etc .... Even though you use only 2 shader you still end up with 20 DRAW CALLS which is bad, if you draw first 10 shader 1 layers then 10 shader 2 layers you end up with 2 DRAW CALLS.
So the order of drawing is important and in most if not all GPU system is gonna determine the number of draw calls. It's not about how many shader must be used, it's about how many time they must be changed.
You can use only 2 shaders but still end up with 100 draw calls because you don't pay attention to their drawing order and you can use 10 shaders and end up only with 10 draw calls because you optimized the drawing and made sure everything draw in correct order.
it's more complex than that but this gives you a simple explanation of why drawing order matters.

If your current view needs as much memory/perf as possible then all normal texts displayed anywhere in that view will take away some of that memory/perf and it actually does add up quick. In that case you want to use bitmaptext instead and it will save you memory/perf for your view. If the current view doesn't need extensive memory/perf then use normal text (but keep the amount reasonable, eg. less than 10)

I don't think jsfiddle would help as this is not related directly to code but instead to browser support.
Here is the situation on all the computer in my company (around 50 MACs/100 PCs):
WIN10 17134.228
MAC High Sierra 10.13.6
NO touchscreen.
(of course this problem DOES NOT apply to mobile or touchscreen device)
IE 11.228.17134.0 : 'TouchEvent' is undefined (PIXI 4.8.0 causes an error) , PointerEvent: ok, MouseEvent: ok
EDGE 42.17134.0: TouchEvent: ok, PointerEvent: ok, MouseEvent: ok
Chrome 69.0.34497.100: TouchEvent: ok, PointerEvent: ok, MouseEvent: ok
FireFox 62.0.2 : 'TouchEvent' is undefined (PIXI 8.2.0 causes an error) , PointerEvent: ok, MouseEvent: ok
Safari 12.0 (13606.2.11) : 'TouchEvent' is undefined (PIXI 4.8.0 causes an error) , PointerEvent is undefined (This is handled by PIXI but when there's no TouchEvent there's no HOVER insteraction) , MouseEvent: ok
1. The original PIXI code (4.8.0) does assume the existence of TouchEvent definition but that definition is not present in many cases which causes error, which in turn causes interaction to completely stop working.
2. My temporary fix does handle the error and this restores interaction for IE and FireFox but NOT for Safari where both TocuhEvent and PointerEvent don't exist.
So my next fix (since the one I posted does not work in safari) will handle TouchEvent check the SAME WAY PIXI does handle PionterEvent check but will have to add the case where BOTH don't exist.

Bumping this since that does seem quite a huge bug in PIXI and yet nobody is responding.
Again: On a computer with NO TOUCHSCREEN, on some browsers, PIXI generates a nasty TouchEvent error and NO user interaction can happen after that.
The fix I posted is working for most browsers except Safari where no hover event are working.
Would be nice if someone would break the silence on this.