I'm having this issue with move_to_element on small elements (dots in a graph) to trigger the mouse over that brings up a tooltip:
If I just move to an element that is ~1.5 pixels round, it fails 20-30% of the time.
I ended up writing a small hack script, spiraling around the element until I hit it and it works 100% of the time, but it's kinda slow.
It consistently seem to find the element about +2,+2 pixels away when not found at first.
To me that just says that the move_to_element function is just not precise enough.
From the doc it says it defaults to the center of the element.
When I look up the element in Chrome dev tools, the tooltip arrow displayed by Chrome to show where the element is located and its size, does not point to the dot itself but several pixels to the right.
So could this be a Chrome issue?
Has anyone experienced this kind of problem? Is there better ways to 'calibrate' the move_to_element functionality?
Related
I've been working on a node project with puppeteer.js for the last few months, but I have just started to use transparency in PDF files and have come across a real head scratcher...
What am I trying to achieve?
3 horizontally adjoined, semi transparent divs, rendered as part of a pdf via puppeteer.
What's the problem?
In html they display as expected. But in PDF a faint line appears between elements which I believe is to do with "stitching". I'm aware that this wont show in print, but I want to get rid of on screen. This is a mock up of some simple content which shows the behaviour I'm experiencing:
What have I tried?
Experimenting with Puppeteer params (antialiasing, flattening, color
flags like -webkit-print-color-adjust) - [Result: no change]
SVG elements with transparent background. [Result: lines still
appear]
A single div using a linear gradient with 3 block colors. [Result: Works when viewed in Acrobat, but has the weird effect in chrome where elements shift slightly to the right (pictured: top row - single div with linear gradient. Bottom row - black boxes used here as a guide for assessing alignment)].
SVG elements using a linear gradient. [Result: Same as above]
Flattening the pdf [Result: This does solve the problem, but degrades
the quality of the rest of the image, therefore not suitable]
I'm finding it difficult to find a solution as I'm not really sure where the behaviour is emanating from (the PDF, puppeteer, browser?). If anybody has any ideas, I'd be very grateful!
Thanks
I am having strange artifacts on a tiledmap while scrolling with the camera clamped on the player (who is a box2d-Body).
Before getting this issue i used the linear filter for the tiledmap which prevents those strange artifacts from happening but results in Texture bleeding (i loaded the tiledmap straight from a .tmx file without padding the tiles).
However now i am using the Nearest filter instead which gets rid of the bleeding but when scrolling the map (by walking the character with the cam clamped on him) it seams like a lot of pixel are flickering around. The flickering results can get better or worse depending on the cameras zoom value.
But when I use the "OrthoCamController" class from the libgdx-Utilities which allows to scroll the map by panning with the mouse/finger i don't get these artifacts at all.
I assume that the flickering might be caused by bad camera-position values received by the box2d-Body's position.
One more thing i should add here: The game instance runs in 1280*720 display mode while my gamecam renders only 800*480. Wen i change the gamecam's rendersolution to 1280*720 i don't get those artifacts but then the tiles are way too tiny.
Has anyone experienced this issue or knows how to fix that? :)
I had a similar problem with this, and found it was due to having too small a decimal value for the camera position.
I think what may be happening is some sort of rounding with certain tile columns/rows in the tilemap renderer.
I fixed this by rounding to a set accuracy, like so:
camera.position.x = Math.round(player.entity.getX() * scalePosition) / scalePosition;
Experiment with various values, but I got it working by using the tile size as the scalePosition value.
About tilesets, I posted a solution here: Getting gaps between tiled textures with libgdx
I've been using that method with Tiled itself. You will have to adjust "margin" and "spacing" when importing tilesets in Tiled to get the effect working.
It's 100% working for me :)
I've been looking all over the place to find the solution to this but haven't had success. I have a Sketchflow project and I want to scale every Screen to the browser resolution on running, as in scaling every element of the current Layout to fit the screen.
Do you want the objects themselves to get bigger to fill the screen or to spread out? For objects to get bigger you can wrap the whole thing in a ViewBox.
I have been searching around and it looks like this question has been asked quite a few times in various places with no answers or responses. That means that I can't be the only one experiencing this.
There is always a delay in the scrolling when you try to scroll a list or panel for the first time. After the first time you scroll a list or panel, there is no longer any delay. Is there a way I can simulate this "first touch" in an effort to remove the delay when attempting to scroll a list or panel for the first time?
I've been looking through the ScrollView and Scroller code and have not been able to find a point where anything heavy or expensive is happening on a first touch.
Any help or direction on how to remedy this would be greatly appreciated.
Thanks!
You can open the Chrome/Safari developer tools and start profiling("Profiles" tab) to see if there is any JavaScript code that is performing badly and causing the hang.
If it's not code that hangs, it might be a web browser issue (e.g. image cache allocation), for example due to the first time that things dynamically change in your web app.
It's also important to try and compare platforms and see if they have the same issue.
It's also often helpful if you specify the Sencha version (I assume 1.x?) and the platform(s) you've had the issue with. iOS/Android/PC can often react quite differently.
I've been trying to render the entire canvas in an IWebBrowser2 control to a bitmap. IViewObject::Draw seems to be the most promising approach, but I can't get it to render anything that would requires a scroll to show. While I could automate the scrolling and stitch the images together, this would look weird with any fixed position elements. Is this even doable?
Additionally, I've tried to set the controller's size to one that would allow the entire contents to display without needing to scroll, but Windows caps the max size to the current screen resolution, so that only gets me partially there.
Any help would be much appreciated. I'm currently doing this in the context of Win7 and IE8, but I don't think that should matter much.
Sorry it took so long for me to follow up with the answer to this.
I wrote up an article detailing how to trick Windows into allowing you to resize a window larger than the virtual screen resolution, allowing functions like PrintWindow or IViewObject::Draw to capture the entire client area (i.e., the browser canvas).
http://nirvdrum.com/2010/03/25/how-to-take-full-page-or-full-canvas-screenshots-in-windows.html
An actual implementation of the technique can be found in my SnapsIE repository on GitHub (username: nirvdrum). Unfortunately I don't have enough karma to post two hyperlinks. The repository is linked from the article though.
It is very likely an IE optimisation that avoid to draw more than required. You might be able to scroll the window and call IViewObject::Draw in a loop without any animation occuring ?
I'm surprised that Windows caps the max size to the current screen resolution. Are you sure about that ?