Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.2 Beta Discussion Thread
I've basically converted the web server's server side WebSocket engine to work in a way that will support RIVA's considerably more robust requirements, including those improvements I made to the RIVA server a couple weeks back, which made a big difference in the server's tolerance and throughput. The RIVA server blasts out lots of msgs that are not in a call/response sort of way. It'll only slow down if it doesn't get an ack every few hundred messages. So it needs an output msg queue to buffer them until they can be sent, and a pool of reusable buffers to use for that queing, and various other changes.

This will work just fine for existing user written (CML) web socket handlers (assuming anyone besides me has ever written any.) It just allows for the vastly higher throughput needed by the RIVA systems. I'll test out the CML demo WS handlers I've done to make sure they still work, then move on to the next step.
Dean Roddey
Explorans limites defectum
(06-06-2017, 09:07 AM)Dean Roddey Wrote: The scheduled event thing has been fixed. It's not the same as before, but effectively it lets you select the run time. Every X minutes doesn't, since that's such a short period. But every X hours lets you select the minute, and every X days lets you select the hour. See the followup releases sticky thread in the main support section. I've not officially posted it yet, since I'm waiting to accumulate more stuff.

I'll look into the log monitor and other stuff you mentioned.

As to the clearing thing, definitely the log monitor only clears its window. It's so you can know anything new that shows up has happened since then. But to actually flush the logs for real you have to do that through the Admin Intf. The log monitor doesn't require a login so it doesn't have the rights to do something like that. In the AI, it's one of the menu bar options. File -> Tools -> Flush Logs.

There's also of course the "/System/Explore Logs" tab, which lets you search the logs.

Thanks - this all works for me.

I've got the web sockets engine converted over now to a RIVA supporting form, and tested out that regular user written e CML type web socket handlers are working on this new substrate. So that gets me back to the point where I can start putting out drops again, while continuing forward with the RIVA migration off to the side.
Dean Roddey
Explorans limites defectum
So of course once I started trying to put all this new stuff together I realized that somethings were now going to have to work differently, so I had to go back and redo some stuff, but I made a lot of progress today, despite a fair bit of sideways movement.
Dean Roddey
Explorans limites defectum
OK, another day of banging infrastructure into place. I'm about at the point now where I can start faking some graphics commands to the client, to basically working out the message handling and graphics drawing infrastructure on the client side. That'll let me make sure that it's basically working right before moving forward. Then I'll pull over the RIVA server's graphics device object, which is what redirects the standard graphics operations to RIVA messages. Then I can make dummy calls on that and test out the above stuff but now through the actual graphics object.
Dean Roddey
Explorans limites defectum
OK, I just got to the point of connecting, getting the login, getting the login result back, getting info on the initial template (to set the canvas size) and processed a dummied in graphics command to draw some text and it showed up. So the most fundamental infrastructure is there. So I'll start working out the core graphics commands and how to implement them with the canvas element, and the pushing/popping of fonts and colors and clip areas and all that, with just dummy commands from the server for now.
Dean Roddey
Explorans limites defectum
I banged out a lot of graphics commands related stuff today. I have the drawing of (non-FX) text basically working. That covers font (face, size, italic, bold), colors, clipping, h/v justification, and pushing/popping fonts and clip areas. That's some fairly key stuff.

I need to bite down and think about images now before I go much further, since that's something that will have to be handled carefully, meaning the downloading and management of them.
Dean Roddey
Explorans limites defectum
Dean, do you think you will be able to support the new web cam widget with your new browser based RIVA client?
Maybe. Once it's working up to current standards (or as close as it can be gotten), I can look at what else might be supported. The color palette is another one.

One gotcha is that the web cam widget currently depends on VLC as a video engine. There would have to be something similar on the platforms it runs on in order to do something like that. Maybe the HTML5 video widget could be used for some stuff in a semi-portable way. Presumably it's oriented towards streaming media sources, but it may not support RTSP or whatever other streaming scheme someone might want, I dunno. I've not had a chance to look at it in any detail.
Dean Roddey
Explorans limites defectum
As feared/suspected, the HTML5 canvas has major limitations. They've made some really bad decisions in the design of it, IMO. Some can be worked around, others are a lot harder, at least to do with any reasonable efficiency.

One really weird one is that lines are draw on the pixel, not between them. In any normal system, if you draw a line from 10,10 to 20,10, that would be a line that starts at vertical pixel 10 and extends down to (but doesn't touch) vertical pixel 11. That's how the actual display works, so it makes perfect sense. The upper left corner of pixel 0, 0 as at the top left of the display. It extends right to just before pixel 1,0 and down to just before pixel 0,1.

The HTML5 canvas draws it straddling the top of vertical pixel line 10, so it's from 9.5 to 10.5. Of course that doesn't exist in reality. Because of that, and however they do their calculations, any line drawn on an odd pixel number will be blurry. So you basically have to add 0.5 to the x/y coordinates of any lines or rectangles and such that fall on odd pixel numbers, at least if you don't want blurry lines. Of course it would work if your display had twice the pixels as what you could actually access or something. But you could achieve the same thing without that silliness and just having the lines drawn in their actual natural positions. It also means that if you draw a line say, 0,0 to 10,0 the top half of it will be clipped off because it's really from -0.5 to +0.5, so half of it is off the canvas. You have to add 0.5 to it to prevent this. Utterly bizarre and useless as best I can tell.

Worse is that clipping paths cannot be removed, except by saving and restoring the whole context state. And it really only supports an 'and' style path combination, none of the XOR, or DIFF, or COPY type styles. So you can't set a clip path, draw something, then set another clip path and draw something. You'd have to save and restore the whole drawing context state around both of them in order to get back to the previous clipping path. The code in the IV has no such assumption. It assumes it can combine and reset clip paths as required, and that drives the clip commands sent to the RIVA cilent. This is going to be difficult to get around.

The worst problem there is that you can't just replace the existing clip path. In a set of nested clipping operations, the last state saved has the previously set clipping path. In order to just set a new path, you would have to have a state with no clipping path to restore, but that's not what's previous on the save stack. You can't do a restore of the state because that will only get you back to the previous clipping path. And unless you can get back to no clipping state, you can't set a new one. That is just retarded.

The only way I can see around it is to do a save/restore around every operation that could require a clip, and then maintain my own clip area stack. I'd have to do a save, then work backwards from the top of the stack to the first 'set clip' operation, set that one, and then work forward to apply any AND type operations. Then it would get popped back off when done. And that would have to be done a lot, which is very inefficient. And it would only be able to support COPY (set) and AND (combine) type clip area combinations, none of the other commonly used ones.

It doesn't support rounded rectangles (and clipping paths thereof), but I was able to implement that myself.
Dean Roddey
Explorans limites defectum

Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 40,404 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 7,293 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,101 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,897 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,794 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 196,358 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,443 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 488,938 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,266 11-01-2016, 10:32 AM
Last Post: Dean Roddey
  How to obtain Beta versions? willsauter 3 3,560 07-15-2016, 04:57 PM
Last Post: willsauter

Forum Jump:

Users browsing this thread: 1 Guest(s)