I'm trying to grab web thumbnails by using X server to run Firefox in headless (Xvfb) X11.
I am looking for a way to know when Firefox FINISHED rendering and then I can use image programs to grab the windows.
Problem: I can NOT determine when Firefox finishes rendering. All I know is that the status bar should have an output of "Done" once it finishes rendering (IE, as shown in Firefox in GUI).
Can anyone know what can I use to determine whether if Firefox finishes rendering a page or not?
What I did is just sleep 40 seconds but this may not always work.
Environment:
Centos 5.7, Xvfb, Firefox 3.6.23
Shell commands:
Xvfb: 1 -screen 0 1024x768x24 &
export DISPLAY=localhost:1.0
DISPLAY=localhost:1.0 firefox http://www.example.com -width 1024 -height 768
sleep 40 **[ NEED some thing to tell me if Firefox finishes rendering ]**
DISPLAY=localhost:1.0 import -window root example.com.png
pkill firefox
Three methods off the top of my head.
Write your own extension that hooks to window.onload and fires the image grabber.
Write a greasemonkey script that hooks to window.onload and fires an alert. Wait for such alert, then run your image grabber.
Periodically grab the image of the Stop button (should be at known coordinates relative to the window) and analyze its color. If it's disabled, the rendering is finished.
Note that I don't think this can be done with FF 4.x and above easily. This is due to "features" of these versions. My recommendation to you is to use some different browser if you can, like Opera. I did not test it myself yet, but I think it does not have all those flaws noticed with FF. See below.
In your case following solution may be efficient:
Write some Greasemonkey script which adds an absolute positioned rectangle somewhere on the screen.
Let this rectangle flash in a 3 cycle when the page has finished loading: red, blue, transparent
Write a script which waits at least 2 such cycles to complete (so it sees red, blue, something, red, blue) and then do a screenshot with the correct timing in the transparent phase.
This should be doable with X11 and VNC and similar. Sorry that I don't have a better solution nor code I can present here.
I for my part would solve it using EasyRFB which I wrote to solve similar things. However I cannot recommend that to you, yet, except if you are very desparate Genius able to read and understand horrible undocumented code fragments with ease ;)
BTW, thanks for noting the idea of a package which is able to screenshot arbitrary web pages, which makes an excellent use case for EasyRFB. Never thought about this myself before.
Looking at GitHub I noticed, that there are some solutions for taking web screenshots based on Selenium or WebKit. These are certainly good for promotional shots, but they apparently cannot cover the general usecase on how users see web pages.
Perhaps it would be interesting to be able to automate screenshots from arbitrary pages as seen by a Windows 95 IE 4, FF 1 or Debian Potato with Chimera etc. I'll have a look into this ;)
Note that there is another posting on Stackoverflow from me.
There is something I call EasyRFB which I wrote in a mix of Python (core), PHP (small web helpers) AJAX and bash (control scripts). It was tested with XVnc but shall work with any VNC. It somehow is able to do what you want, but beware, it is development code, undocumented, complex and horribly written and may be faulty. You can find it there:
GitHub: https://github.com/hilbix/pyrfb/tree/easyrfb
My old development directory: http://hydra.geht.net/easyrfb/
It was written for following purposes:
Being able to control a remote GUI from a Mobile even in a situation where the Internet connection is extremely slow and extremely unreliable
Complete UI automation / replace mouse by commandline
Automated QA tests, based on what the user sees in contrast to what the browser or some windows spy program sees, in cases where the output needs not to be pixel-color-perfect as well
It was not written to be fast nor efficient nor easy to use nor for others (yet). It works, for me, somehow.
What it does:
is Web centric and gives a AJAX Web frontend to VNC servers, somehow.
keeps a highly compressed .jpg updated to the contents of the screen.
can take lossless screenshots
is able to fuzzy-match templates against the contents of the screen
templates can be Web-edited with edit.html - however this editor is basic, not self-explanatory and not documented at all
Shell scripts can be written which can wait for these templates to match and send commands like keypresses, mousemoves and clicks to VNC
There are some .sh scripts which could help to understand how this is done, but I am not able to publish the really helpful stuff yet, sorry
Nothing is documented and I am not able to explain how to use it. Either you find out yourself or you are lost. Sorry. Better don't even look at it, it might hurt you.
And now to the problems noticed with FF while doing all this:
Newer FF versions fail to properly update the screen. The last version known working correctly at my side was the FF 3.6 series, all later sometimes develop some strange behavior.
For example:
Newer versions now update the status before they update the screen contents.
Also they have such a high CPU and memory demand, that finishing the last step on updating the screen can take some time. On slow hardware (like the NSLU2, never tested) I think it might even take minutes after the Spinners etc. are already in the "finished" state.
So even looking at the spinner to become gray including(!) naive Greasemonkey solutions which notify about "onload()" both fail with FF 4.x and above, because parts of the screen may still not be updated when you detect that it is ready.
Maybe it has only to do with XVnc, perhaps there is a bug in my scripts which triggers all this, but with FF 3.x everything was right and I think, reverting to an old version would immediately solve all those problems seen. (But I already have workarounds in place for all those trouble. But I cannot publish that scripts, sorry.)
It gets worse.
FF 4.x and above apparently delay event processing a bit. So jumping the mouse out of the scrollbar often keeps it highlighted, I think the event does not reach the scrollbar.
On a normal desktop you do not jump your mouse, but my solution is able to do so. The fix is to generate additional, superfluous mouse movement events to have FF do the right thing.
Also I noticed, I really have no idea if it is due to FF or the web pages shown in FF, that sometimes things do not land where they are supposed to be. I never observed this before with FF 3.x though. The trick which solves this is to reload the page. It might have to do with incremental screen updates, but I did not dive into this yet as the retry (automated clicking on the reload button) works for me.
Related
Well, the title almost says it all : Why should I not move a GUI (e.g. Gtk) window on screen from the code ? In Gtk 3 there was an API for moving windows on screen, but it was removed in Gtk 4, because it is not good to move a window from code; only the user should do so (don't ask me to provide sources for that, I read it somewhere but have forgotten where and cannot find it). But I cannot think of any reason why it shouldn't be good, but of several reasons why it could be good, for example to restore the position of a window between application restarts. Could you please shed some light on this ?
The major reason why is that it can't possibly work cross-platform, so it is broken API by definition. That’s also why it was removed in GTK4. For example: this is impossible to implement when running on top of a Wayland session, since the protocol doesn't allow getting/setting global coordinates. If you still want to have something similar working, you'll have to call the specific platform API (for example, X11) for those platforms that you want to support.
On the reason why it’s not supported by some display protocols: it’s bad for UX and security. In terms of UX: some compositors can have special behavior because they need to work on a small device, or because they have a kiosk mode in which everything should always run fullscreen, or they provide a tiling experience. Applications positioning their windows themselves then tend to give unexpected behaviour. In terms of security: if you allow this, it’s technically possible for an application to reposition and resize itself so that it covers your screens while making itself transparent, without it being noticeable, which means it has the possibility of scraping all input.
Our app loads extremely slowly, especially the pictures, and the developer has not been able to come up with a solution to this. The movements are slow and the buttons are slow in response (works on the 2nd or 3rd press).
The stability is terrible, for example the whole screen moves to the left by 2mm when you press a back button.
The app downloads information from the server every time it runs. We have tried changing the server, but this did not yield any results.
The current solution is to make the images smaller (compress them) to make the app run faster, but we are dubious if this will work.
Is there anybody who has had the same problems with their app?
I would be very grateful for any suggestions for how to fix this. We need it to be fast and responsive.
These are very vague, general issues. You ideally need a developer to take a look at the whole problem.
Some things they may look into would be:
Is data access asynchronous?
Are there transitions running on the
page?
Are styles being added on hover or focus?
If the app is written badly, simply chucking more resources at it probably won't solve the problem.
I have created a gif in photoshop. It has two frames displayed for 4 seconds each and is on a loop forever.
For some reason the image freezes on the second frame and does not continue to load in some browsers (The exact information about browsers and / or versions is unclear at the moment but it has happened in the latest version of chrome).
The image is embedded in the code in the standard way, no javascript is used and nothing is changing the element.
Does anyone have any idea what could be causing this? Everything I have searched for so far seems to result in people saying "Oh, I forgot to put make the gif loop forever" instead of any real reasons for causing this problem.
Thank you for your help!
Edit: Sorry I didn't think about putting an image in the original post. He is an example of one advert which doesn't seem to work.
Because the current image displays correctly in everything I've tryed so far, try to create image in different application.
Some applications you may try:
GIMP - tutorial
Some freeware crap.
I'd vote for GIMP. Its complicated, but its free and it has wide user suport.
If you still fail...
Now its time to check the enviroment. First, open the image on different machine. Maybe there is something wrong with your browser instalation. In this case, reinstall.
Try to upload on different server. Maybe your browser does not correctly decompress deflated data or has other communication issues.
I have been developing a media player browser plugin for the past few month using Firebreath, but I do not think this is a Firebreath problem.
Currently I am stuck on this weird problem that occurs when one tries to reload the webpage containing the plugin. The image that was being displayed before the reload will stay stuck on the top of screen. The new reloaded plugin will be alive and well behind it but the old image will stay stuck their on the screen forever. If I scroll or resize the browser or even change URLs the image will stay put, however If I move the browser the image will follow. The image stays after closing a tab, but leaves when closing the window
Here is a screenshot that demonstrates what I am talking about.
http://i.imgur.com/asB7i.jpg
( I am a new user so I cant post images )
Has you can see I left my plugin's page and went to the Firebreath website and the image still persists.
This problem happens on both windows and linux, much less frequently on linux, and happens when using both directx and opengl. But only happens on chrome.
Just wondering if you, or anybody else, has any thoughts, suggestions, or insights as to what might be happening. I've tried everything including atrocious hacks and nothing seems to work.
Thank you.
Your problem is most likely that you aren't tearing down your directx or opengl context when the DetachedEvent fires. AttachedEvent is the earliest you can set it up, and DetachedEvent is the latest you can leave it running.
In Vista and later, if an app becomes unresponsive, the Desktop Window Manager is able to handle redrawing it when necessary (move a window over it, drag it around, etc.) because it has kept a pixel buffer for it. Windows also tries to detect when an app has become unresponsive after some timeout, and tries to make the best of the situation -- I believe it dims out the window, adds "Not Responding" to its title bar, and perhaps some other effects.
Now, we have a skinned app that uses window regions and layered windows, and it doesn't play well with these effects. We've been developing on XP, but have noticed a strange effect when testing on Vista. At some points the app may spend a few moments on some calculation or callback, and "if a message has not been retrieved within 5 seconds, the DWM declares the window to be hung" (MSDN - Preventing Hangs in Windows Applications). It seems that when this kicks in, a strange graphical problem occurs: any pixels that would be 100% transparent due to the window regions turn black, which effectively makes the window rectangular again, with a black background. There seem to be other anomalies, with the original window's pixels being shifted a bit in some child dialogs.
I am working on reducing such delays (ideally Windows will never need to step in like this), and trying to maintain responsiveness while it's busy, but I'd still like to figure out what is causing it to render like that, as I can't guarantee I can eliminate all delays.
Basically, I just would like to know what Windows is doing when this happens, and how I can make my app behave properly with it. Skinned apps have to still work on Vista and later, so I need to figure out what I'm doing that's non-standard. I don't even know exactly how to look for information into how Windows now handles unresponsive apps, as my searches only return people having issues with apps that are unresponsive, or very rudimentary explanations of what the DWM does with such apps. Heck I'm not even 100% sure it's the DWM responsible, but it seems likely. Any potential leads?
Photo of problem; screen shots won't capture the effect (note that the white dialog's buffer is shifted -- it is shifted exactly by the distance it has been offset from the main (blue) window):
This is standard behavior; you can also notice it in Office 2007 / 2010 when they freeze.
I have found that it is called 'ghosting' when it does this, and it was introduced in XP (though it seems DWM takes it a step further since it keeps track of every app's pixels). It is possible to disable it for the duration of your app's life with DisableProcessWindowsGhosting(). Some folks say that it is not recommended, but considering how badly it plays with layered windows, the downsides of turning it off are negligible. I've tested it and it does precisely what it claims; now if the server takes a little longer than expected to return, it won't mangle the entire interface.
If there is a better way to get my layered windows to work with Vista/7's handling of ghosting without disabling it outright, I'd certainly still be interested, but I'll probably just accept this as the answer otherwise.
I think there are basically two things that will help with this:
First, like you've been doing, try not to hang in the first place: do as little heavy lifting in UI threads as possible.
Second, don't use multiple top-level windows to implement what the user is meant to see as just one; instead, do the compositing yourself. That will prevent the layers from being moved out-of-sync from one another.