we use EasyRTC for sending image captures from iPad (we create screenshots "manually" and send them via socket.io) to web browser. On the server we have EasyRTC v.1.0.12 and Socket.IO v.0.9.16. It's hard to say what happened (i've just joined the project and encountered this issue. PM says that it was ok some time ago) but recently we started to notice that some frames are blacked-out. We are debugging this issue for few days and we're running out of ideas. We are not sure where the problem is.
We now that we send correct images from the device. We noticed that it happens only when the image is different from previous one (but not always... it's easier to observe it on the weaker internet connection). When the image is "repeated" (i mean it looks the same but from iPad perspective we create it as new instance) everything is fine.
In attachment you can find info from Chrome network debugger. As you can see in thumbnails or images are ok. These with Size/Content from cache are ok but there with Size 0 and Content > 0 are ones which gives black screens when we want to draw them on the canvas.
Any idea what we're doing wrong? How to debug it? It seems that images are somehow downloaded later than we try to draw them?
Our server is on AWS.
You are trying to send the images up as base 64 encoded jpegs. Basically big text strings. The first thing you should be asking yourself is: is the text string I'm sending up getting to the server, or is it getting truncated? Check the length of the string being sent versus the length of the string being sent, and then check the start and ends of the string.
Finally we found the solution which is pretty easy. It turned out that we was trying to draw an image before it was fully loaded. So what we did was to move drawing code to image.onLoad method and now it works as expected.
img.src = "data:image/png;base64, <img content>";
img.onload = function(){
canvas.drawImage(img);
}
Related
i have very basic knowledge base in python, and i am working on a project to interact with Photoshop.
i managed to do most what i want expect a last issue
as my program is continuously reading from Photoshop (foreground colour) and writing to Photoshop the same hing. my issue is when the program is busy and not ready to accept data such as when a dialog window is open, python try to send data and fail and stop the application
i am using python 2.7 and following some of the codes I am using
I guess I need to check the port if it is ready before sending anything
psApp = win32com.client.Dispatch("Photoshop.Application")
psApp.foregroundColor = solidcolor #to send the new data to Photoshop
thanks
Many thanks to all who tried to help me with this issue...
I managed to solve it buy using try, except ... also I figured it out that the break was happens to the timer that apply the values not to the protocol itself
many thanks again
I have the project to develop an application that would allow a computer to 'send' a window to another computer.
In order to do that, I need, of course, to capture the concerned window's output from my program.
Google searches leaded me to no relevant result, neither with libX11 nor libxcb.
I also tried to record screenshots with xwd and import, but as they are quite slow, I'm getting up to 3.5 fps
Any help on how I could do that will be welcome (either using libX11, libxcb, or something else)
By the way, I attempt to use c++ for this program
Thanks for reading,
Edit:
The fps test was made without sending files. It was just like "I took screenshots for 5 minutes, and I got 900 pictures"
I think you will need to record screenshots and compress them before sending over network to make things faster. Also, you would need to decrease the quality of the screenshots (user configurable) to make it faster.
Plus there are different techniques to send only the changes (diff of screenshots) to the other computer.
I am developing a multi-viewer VNC client using libvncclient (part of libvncserver) and Qt. It's been a little challenging but I finally have the app working fairly well, except that it will not show cursor shape changes from the server. I would like to overcome this issue so I can share this software project with the world, as I do with most of my other projects.
I have tried this to make libvncclient show cursor shape changes:
client->appData.useRemoteCursor = false;
and that doesn't show cursor changes in the framebuffer. Next, I tried handling the cursor changes myself, using:
client->appData.useRemoteCursor = true;
client->GotCursorShape = got_cursor_shape_change;
and while the got_cursor_shape_change callback would be called when a cursor shape change happened on the server, the buffer for the cursor image, rcSource, and the buffer for the cursor mask, rcMask, were not valid images.
I have done searches on the internet for help on this problem but resources besides the official documentation are pretty slim. I contacted the developers about this issue, but they say that what I've tried should work.
EDIT: Also, other viewers, such as TightVNC, TigerVNC, gtk-vnc, etc are all displaying the cursor shape changes from the server, so I know it's sending the changes properly.
Does anyone have any clues as to what I should try?
Thank you in advance. :-)
This is resolved.
The problem was that a very old version of TightVNC (2.0.x) was installed on the remote machine I was testing with. Once updated (to 2.7.x), the remote machine's cursor is visible and shape changes happen in my viewer. The following is what is working:
client->appData.useRemoteCursor = false;
I'm having problem making a permanent calibration in my embedded solution. I'm developing a Qt-based app for a Embedded Linux environment with touch screen. For this last part, I use tslib (configured by previous developers).
In what comes to simply calibrate the touch screen, everything is fine: ts_calibrate runs and creates the pointercal file correctly. If after calling ts_calibrate I run my Qt app (or ts_test), I can notice that the calibration is successful.
The problem is that the calibration results only works for 1 opening of my app: I calibrate with ts_calibrate, run my app, close it and if I run my app again, the screen is one again non-calibrated.
Now obviously I don't want to have to call the calibration each time my app is closed and reopened. The question is: how to make the calibration results become permanent? (that is, till another calibration is made)
Extra info:
I did some research on the web and I found this SO thread telling about a way to handle this problem using QWSServer. At first I disliked this solution since it depends on the Qt framework to do the job (I was expecting a more general, "C++ solution" (or a call to a script, whatever)). But I implemented it and it worked - but only in a specific case, namely, if I calibrate, open my software, close it and reopen it, then the calibration is maintained. But the problem nevertheless persists if I shut down the hardware completely, turn it on and run my app without a call to ts_calibrate (reloading the Linux kernel in the process); so this show to be only a partial solution and, therefore, not acceptable.
Trying to find the source of the problem, I created a copy of the pointercal file just after calibration and another copy of it after shutting down and turning up my hardware (and confirming that the calibration was over) and I noticed that the file was changed in the middle despite no call to the ts_calibrate or similar app was made:
After calibration:
55438 118 -1920736 -543 -36058 34531168 65536 800 480
After hardware shutdown:
-55040 1280 2526720 -288 35040 -34398240 -62768
The terminal log for the linux boot (tftp; bootm command) don't mention pointercal or a relevant calibration process.
Edit
I recently learned that the pointercal file located inside /etc/ is changing between sections because that entire folder is made new when the hardware is restarted. So what is essentially happening is that Tslib is going after a file that is constantly reset to default each time the hardware is restarted, and what I need to do is to configure Tslib not to look there, but to a more secure folder (in my case, the SD Card). The new question now is: how to do that? I know I have to configure the tslib.sh file making the TSLIB_CALIBFILE variable point to the new location of pointerscal, but tslib.shis itself inside /etc/, being itself temporary.
You have to change TSLIB_CALIBFILE in the image loaded via tftp.
That should do it, since you just have to change that once.
Basically I am writing a client program which receives response and logs from server, the client is also able to send request to server for different information. I used curses and output looks pretty good. It looks like VI, output at the top and user on Client end enter command at the bottom. Only thing is I am not able to scroll back.. My boss told me to make it like "more command in linux" and I want to stick with my solution and add a scroll bar on the side for output window...
I was thinking Server sends logs randomly and it's nearly impossible (or too hard) to make it look like more...
If you maintain a list or array of lines in your client and ask ncurses to paint a range of lines as a sliding window, you can slide your window up and down in response to ^F ^B ^U ^D ^Y ^E commands, which just repaints the screen with different indexes.
I would skip trying to draw a scrollbar though: It would look out of place on a Linux system. Not even mc has scrollbars. Just show a content summary in the bottom line, similar to vim's Top, Bot, All, N% when :set ruler is turned on, that'll feel most at home.
I'm not entirely sure if you are asking about how to implement scrollback or how to draw a scrollbar with ncurses. My guess is the second.
Assuming your ncurses is compiled with Unicode support (remember to set the environment correctly when initializing ncurses, look into "setlang"), you can use following characters:
Unicode:
▲ - U+25B2 BLACK UP-POINTING TRIANGLE
▼ - U+25BC BLACK DOWN-POINTING TRIANGLE
▮ - U+25AE BLACK VERTICAL RECTANGLE
ASCII:
176 - ░ Light shaded block
177 - ▒ Medium shaded block
178 - ▓ Dark shaded block
219 - █ Block block
Writing the code to display the dark block at the right place should be quite straightforward.
If I understood your question wrong, my excuses.
Another possibility is to re-write your client as an IRC bot or an IM client. Users send messages either to the client directly or to a specific channel, and the bot performs the action and sends back any necessary replies.
The beauty is you get to skip all the user interface stuff yourself -- scroll back and history is handled via irssi or xchat or some other client. Users can run the client they like the most.
Logging can be handled via a central mechanism, published to the world, or given to specific managers / administrators as needs dictate.
The downside is that you have to maintain and run an IRC server or XMPP server. If you're already using them elsewhere in the organization, and it is appropriate to use them for this, the leverage might be worth it. If you're not already using one, the savings in the client might not be worth the expense of maintaining yet another service.
A team I was part of in the past loved having an IRC interface to BuildBot to report check-ins, build success, build failures, test success, test failures, for our continuous integration build and test setup.