Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Preview of new Web based RIVA client
#31
I made some changes and things went haywire and it was quite a struggle to get things back. But, along the way a lot was learned and improved. One thing that keeps coming up and then going away is that the stupid browser won't send out WebSocket messages immediately until there's a certain amount of outgoing data built up. But it isn't consistent about this. It did it for a while and then went away and I convinced myself it was just me doing something stupid but it started doing it again. This is horrendously stupid for WS msg transmission to work this way, given the entire point of having WS to begin with.

It was biting me on click/release events. I'd click and nothing would happen. Then I'd click somewhere else and the previous click suddenly would happen on the thing I originally clicked on. It was because the original msgs wouldn't get sent until the new ones forced them out. Or, if I just let it sit, it would happen the next time my client sent a ping msg, or if the clock updated on the template and forced a small redraw.

I'm currently trying to send some dummy messages in order to force these other messages to get sent. Really stupid. There should at least be a 'flush' command to force a send of any accumulated data. There's no way to know if this is really going to work consistently.

And I had a go around with the fact that hiding a DIV doesn't necessarily hide the things inside it. So the check mark images on the popup menu would sometimes show up over my canvas. So I had to combine z-order and visibility to get it work right.

But anyhoo, it's working well now. I still didn't get to the full screen stuff because of all of the above. And I just realized that I never did the work to put the web sockets processing in a web worker so that it will continue when the WebRIVA client is not the visible tab. I'll tackle those tomorrow.
Dean Roddey
Software Geek Extraordinaire
Reply
#32
OK, I have the WebRIVA client using a web worker to manage the WebSocket connection. That seems to be correctly allowing it to stay connected while it is not the active tab. I was hoping maybe that had something to do with the above stuff of not sending out the messages in a timely manner, but it still does that. So I'm just forcing a ping messages out after each press/release to force it out.

One thing has become clear which is that really the canvas is just shy of useless for standard 2D UI type stuff because it insists on the right to anti-alias all operations, even if they are rectangular and fall on pixel boundaries. That's what is behind all of the crazy problems I had with lines showing up around things. Even if you just do an image blit, which of course is pure pixel aligned stuff, and even if you have don the translate(0.5, 0.5) thing to get around the ridiculous way they place pixels straddling the actual line between real pixels, it still will anti-alias the edges, which can leave artifacts around the thing being drawn. It still is doing it sometimes, despite my best efforts to get around that.

I don't know how they expect anyone to render pixel exact content under those circumstances, unless you redraw the entire contents every time you update. Maybe they expect that since I guess it's a common scenario in games where the whole scene is composited onto a back buffer, which is swapped to the screen on the next retrace period, and they then start filling up the other one, and the process continues. If you did it like that you'd never see those types of artifacts, but it would be hugely inefficient for something like the IV and particularly so for the RIVA version which would require a full batch of drawing commands to be sent for every change (such as having a time showing seconds on the main template which would cause it every second.)

Oops, I just realized that the client has to send a ping to the server every so often to keep it from dropping the connection if nothing else is going on. But that is still being done in the main application code, which means it'll stop if not the active tab. So I'm going to have move that over to the web worker as well.
Dean Roddey
Software Geek Extraordinaire
Reply
#33
BTW, web workers and Typescript are a bit of a disaster right now. The file has to be loaded separately from the standard Typescript module loading scheme. It is passed to the web worker object which loads it itself. And the typescript typings information isn't correctly loaded in the web worker because it doesn't know it's a web worker, so I had to fake some parameters to make it happy because the IDE and command line compiler use the wrong typings file to validate the calls. I basically stripped the web worker code down to straight Javascript, and just copy it over to the output directory during the build.
Dean Roddey
Software Geek Extraordinaire
Reply
#34
Wow, that was another hour of completely psychotic weirdness. But I think I have the web worker/socket stuff working well. We'll see after some more testing tomorrow. There was some extra javascript context weirdness that I wasn't dealing with because I just wasn't used to having to do so because it's taken care of by Typescript. And I don't get any compiler help on the raw javascript file that implements the web worker.

But it seems to be correctly reconnecting as it should when the web server goes away and comes back, and I've got the ping stuff moved over to the web worker so it will continue to ping the server and keep the session alive. I'll let it sit in a background tab for a while and see if it falls over. So far it's doing OK.

I've added the option for a 'session name' to be passed on the URL, which will be used in WebRIVA specific log messages, to make it easier to figure out which one it is. I could just set it for you based on host name, but I'm not sure what 'host name' means on, say, a phone.
Dean Roddey
Software Geek Extraordinaire
Reply
#35
It's still doing the delayed messages thing. I'm starting to wonder if maybe I'm causing that somehow. I'll dig into it tomorrow. It seems to happen if I click on two different things to quickly, so that may be a clue.
Dean Roddey
Software Geek Extraordinaire
Reply
#36
OK, I finally figured out the issue with the delayed input. It was the menu coming up that was getting things out of whack. So I just reset some state info upon close of the menu to force it back to a known correct state and that seems to take care of it. I keep track of whether I'm tracking a press (waiting for a release) and it was getting my tracking state out of whack. I guess it was eating the release.

I wouldn't bother but it's a huge win to only send move/drag events when they are required and they are only actually needed when the user has pressed down and then moves. That's a good bit of traffic, so not sending unless required is a good thing.

So, anyhoo, I appologize to the browser websocket people, since it wasn't their fault. It is my understanding that they can buffer, but it's not the problem in this case.
Dean Roddey
Software Geek Extraordinaire
Reply
#37
Oops, I take that back, it was apparently both those things at the same time, so no wonder I was freaking out. Even if I fixed it it would then break for the other reason. If I don't send the extra message after input, it will not send them until the next input, so again it gets into a situation where the previous release doesn't show up until the next press, and the cycle continues.

OK, so I un-appologize to the browser websocket people, and their evil buffering schemes.

Anyway, having fixed the above and putting back the sending of the extra ping message after each input to force the messages out, it seems to be working fine consistently.
Dean Roddey
Software Geek Extraordinaire
Reply
#38
Just when you think you are out, it pulls you back in. I had originally used a double click to invoke the menu, but that was kind of messy. So I decided to change it. I started with the touch input, which is the most complex. I changed it to use a two finger press/release. In the process of doing that, I started seeing all kinds of weirdness, and have spent the rest of the day figuring that out.

In the process, I FINALLY figured out the freaking issue with delivery of touch input. And, yes, it turned out to be my fault. So I re-apologize to the browser web socket team.

The problem was that back a while I changed the structure of the server to use an event driven scheme, where the system wakes me up if there's data available to read or messages queued to send. I associate an event with the socket. If that event gets triggered, you reset the event then read a message, then go back to the top. You don't try to read more than that even though there could be more, since the point is that you want to interleave in and out and the system will re-trigger the event again if there is more data available, so you keep waking up for this and then that and then this, until there's nothing to do again.

But, I'm using a data source object to manage the socket, not the raw socket. The reason being that data sources come in various flavors, one of which is an encrypted versions (for HTTPS.) It wraps around the socket (and potentially other data sources/sinks.) In this case I know I'm using a socket, so I'm creating a socket based data source, which lets me do the above stuff (associate an event with the socket to be woken up when data is available.)

AND!! The data source buffers. So, I'd read one message when I woke up. But, if the data source had buffered up more than one, I wouldn't try to read it, assuming I'd be woken up again next time. But I won't necessarily be because all the socket data may already read, and it's there in the data source's buffers. So there was often a message stuck in the data source buffers, and only when a new message came in would I then try to read, but I'd still not read them all. Once I it a situation where two messages came in quickly, that would get one buffered and I'd be behind forever. That's why I noticed earlier that two quick clicks was causing the problem.

And presumably this is affecting the old RIVA server as well since I made these changes to it first. I need to look at it.

Oy vey that was driving me crazy. The up side is that input is much faster now. It was also affecting other things like moves, but that wasn't so obvious because moves come in a bunch generally. But it was making moves 'chunky'. There isn't much traffic from the client to server, so that made it harder to figure out.

So, the moral boys and girls, is don't be freaking stupid!
Dean Roddey
Software Geek Extraordinaire
Reply
#39
I still need to now figure out a better way to invoke the menu if using a mouse, but that's a fairly small thing. And the double press/release is much better definitely.

There is definitely still an issue where the close of the menu bleeds a touch/mouse event through that gets seen by the canvas and that causes a bogus touch operation. So I need to figure that out still.

But, anyhoo, that was a huge breakthrough and something I was really starting to worry about. It could have made all this work useless. With the web worker stuff worked out now, it's getting pretty nice. It stays running just fine in the background. The browser will slow it down, but not enough to kill it. Well, I've not left it in the background for hours, so maybe something might happen. I'll have to try that.

Oh, and the old RIVA client wasn't affected because it's using a raw socket.
Dean Roddey
Software Geek Extraordinaire
Reply
#40
It's pretty crazy how difficult things can be to figure out. I kept getting a situation where, after I dismissed the popup menu, the next touch would just blank the screen. I couldn't figure out to save my life what was going on. Then I noticed that if I invoked the menu by doing the two finger thing on the left side of the template it wouldn't happen, only on the right. That had to be a clue but I couldn't figure out what.

I just got PO'd and swiped my finger left to right and it showed up back up. So I swiped right to left and it went blank again. So I brought up the regular IV and did it and it happened there, sigh.... The main overlay is twice the width, because it scrolls over to show the right side. But until you select a section, there's nothing there. So it is just scrolling it left and the right side is black.

So then that finally showed me what was going on. The invocation of the menu is somehow leaving a release event unhandled, though I can't see how that happens because I watch for all touch points to have released. Or maybe it's the close button on the menu. But the mouse gets seen at that position. If it's to the right, and my next click is to the left of that, it sees it as a quick mouse move, i.e. a flick, so it scrolls the whole contents left.

I guess it has to be from the invocation because if I invoke by clicking on the left side it doesn't happen, but if I do it on the right it does. The close button is always in the same place. But I'm waiting for all touch points to be released before I do anything. Oy! If it ain't one thing it's another.

That argues for a selective gesture disabling mechanism on overlays I guess, so that they can prevent scrolling in particular directions under particular circumstances. It still needs to be able to scroll up and down via gesture, to show more tiles, so I can't just disable it altogether.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  The RIVA Comm Buf Mgr pool is full and cannot be expanded any further zra 52 5,851 05-14-2017, 08:54 PM
Last Post: Dean Roddey
  HTTP-based Trigger Driver Docs znelbok 5 1,039 03-11-2017, 09:34 PM
Last Post: Dean Roddey
  Client Side Drivers pinballmark 2 901 12-13-2016, 01:31 PM
Last Post: pinballmark
  Room config HTML based app preview Dean Roddey 5 1,081 11-05-2016, 02:53 PM
Last Post: Dean Roddey
  5.0 Preview Stuff Dean Roddey 108 7,446 11-01-2016, 11:06 AM
Last Post: Dean Roddey
  Repository + RIVA problems chmilar 7 1,254 03-29-2016, 02:14 PM
Last Post: Dean Roddey
  4.8.2 preview Dean Roddey 18 1,874 01-26-2016, 12:59 PM
Last Post: Dean Roddey
  Repointing CQC Client to new server address? Deane Johnson 11 1,684 11-10-2015, 02:11 AM
Last Post: Deane Johnson
  Client won't connect Deane Johnson 12 1,678 10-30-2015, 03:18 PM
Last Post: Deane Johnson
  Graphing on IOS Client zra 1 1,103 04-04-2015, 09:29 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)