Official RIVA thread

[Dean Roddey]

This thread is for official discussion of the RIVA protocol. Since it is fairly new, there are likely to be questions or issues or requests. So use this thread for such general discussion. If you are creating a product, feel free to create your own thread for discussion particular to that product.

The latest RIVA protocol header is attached. The protocol is discussed in technical detail in the Remote Viewer Protocol technical document, available via the web site. This version of the header is valid for 3.0.13 and up.

Here is the latest (V2) RIVA development guide document:

http://charmedquark.com/Web2/Downloads/Documents/3_4/RemoteViewerProtocol_3_4.pdf

Here are the changes for Version 2 of the protocol. Everything else is the same:

// ---------------------------------------------------------------------------
// All of the Version 2 protocol stuff is below here. This does make things
// a little less readable than having it all together, but it makes it far
// easier to track changes, which is really the most important for sanity.
// ---------------------------------------------------------------------------
namespace kCQCRemVComm
{
// -----------------------------------------------------------------------
// New V2 opcodes
// -----------------------------------------------------------------------
const tCIDLib::TCard1 c1OpCode_DrawPBar = 21;
const tCIDLib::TCard1 c1OpCode_NewTemplate = 75;

// -----------------------------------------------------------------------
// Values for c1Dir of DrawPBar, and possible other direction
// oriented stuff in the future.
// -----------------------------------------------------------------------
const tCIDLib::TCard1 c1Dir_Left = 0;
const tCIDLib::TCard1 c1Dir_Right = 1;
const tCIDLib::TCard1 c1Dir_Up = 2;
const tCIDLib::TCard1 c1Dir_Down = 3;
};


namespace tCQCRemVComm
{
// -----------------------------------------------------------------------
// c1OpCode_DrawPBar
//
// Draw a progress bar
// -----------------------------------------------------------------------
struct TDrawPBar
{
THeader hdrInfo;
tCIDLib::TCard1 c1Opacity;
tCIDLib::TFloat4 f4Percent;
TRVArea areaSrc;
TRVArea areaTar;
tCIDLib::TCard1 c1Dir;
TRVColor clrFirst;
TRVColor clrSecond;
TRVColor clrFill;
tCIDLib::TCard4 c4ImgSerial;
};


// -----------------------------------------------------------------------
// c1OpCode_NewTemplate
//
// A new base template has been loaded. The template path is provided as
// text in the usual way.
// -----------------------------------------------------------------------
struct TNewTemplate
{
THeader hdrInfo;
tCIDLib::TCard4 c4Width;
tCIDLib::TCard4 c4Height;
};
}

[Dean Roddey]

As of 2.4.48, a couple slight additions were made, and the header above updated.

- There is a new Ping command which simple clients can use if they want a persistent image download connection. There's a chance in certain simple templates that there will be no changes for over a minute, and the image server could time out. So if you've made no snapshot requests in around 45 seconds or so, send a ping to keep the connection alive. It's just an opcode so it uses the TGenOpCode structure.

- There's a new TGenOpText structure for those simple commands that include just an opcode and a piece of text.

- The server will send a new PlayWAV command (using the new TGenOpText structure) when the client has configured a WAV file to be played. It will include the wave file as text after the structure in the usual way. You should play it asynchronously, since you don't want to block to play some long file. The user will have to have placed the WAVs such that the path you receive is accessible from where you are running, else obviously your attempt to play it will fail.

[gacevich]

i have not spent much time trying to understand the riva, other than i think it is designed to run on machines with low computing capacity. assuming i am right, would using riva on my samsung q1 improve its responsivness?

[sic0048]

Actually RIVA is designed to allow some sort of CQC IV to run on something other than a full Windows OS systems. So unless you changed your Q1 to run on some other OS (like linux, Windows CE, etc), RIVA will not play a part in your Q1 life.

[gacevich]

ok, thanks. i'll continue to ignore riva.

[Dean Roddey]

Actually it could still. It's a lower resource consumption viewer as well. Sergio reported that it runs faster on their Vidabox tablets than the regular one. The regular one is still best otherwise. But on a small device, it's possible that the remote one may work better.

[sic0048]

Actually it could still. It's a lower resource consumption viewer as well. Sergio reported that it runs faster on their Vidabox tablets than the regular one. The regular one is still best otherwise. But on a small device, it's possible that the remote one may work better.

Will there be a XP or Vista version created by CQC? Or is that something that would have to be writen by someone else? I guess it sounds like Vidabox is already experimenting with one.

[Dean Roddey]

There is an XP, eXP, Vista version in the current beta releases. Mark has a .Net version going in the lab as well.

[potts.mike]

riva doesn't support web widgets though does it. If we were to use it on xpe we would lose our weather and traffic maps?

[Dean Roddey]

No, because of how it works it can't support web widgets, and for now it won't support the progress bar.

[brianmount]

I am in the process of developing my iPhone RIVA client. I have managed to get far enough to log in successfully, which is good. Some notes and questions:

I'm glad that I took my friend Rob's suggestion to look at the .Net RIVA code after banging my head against the wall trying to figure out how to get the Blowfish code working. I see in your code that you are converting your 16-byte blocks into 4-byte chunks using big-endian encoding. I hadn't anticipated that. When I switched to do likewise, it magically started working. Is there a reason why you do it that way? It would be good to make a note in the documentation, for the benefit of future generations of RIVA developers.

It appears that you are using four-byte lengths for the strings that appear after the message structure. The header file reflects this. But the documentation states that the lengths are stored in two bytes. That should be corrected.

On the same subject, I would have thought from the documentation that only messages containing a text string would have the length bytes and string at the end. But, looking at what the server is sending as a LoginChallenge, I see that the payload includes four extra bytes, which I presume are a string length, even though there's no string in a LoginChallenge. Is it the case, then, that all messages include a length, which is set to 0 if there's no string? Should I likewise always include a length in my messages, and set it to 0 if unused?

How does the TException message look? Does it have seven length-and-string pairs, or does it actually have an eighth length at the end set to 0, like a null termination? Is there a way to get the server to generate a TException, so I can test my code?

On a purely cosmetic level, while I was playing around trying to figure out the length byte thing, I deliberately sent a Ping message first, instead of a LoginRequest, to see what would happen. The server logged an error saying that it received a LoginRequest opcode when it was expecting a Ping opcode (the reverse of what actually happened).

Thanks.

[Dean Roddey]

The login challenge can include an error message if the request fails. Only those structures that include text will have those extra bits at the end, but in some cases the string is empty, in which case you have an empty length. So if the c1Error field of the login challenge is set, there's a string at the end with the error message, else it's the empty one.

The exception is indeed a set of length/text pairs at the end. So it will generally require a special decoding method, where's almost everything else has no text or one piece of text and can be handled by a single method.

On the Blowfish blocks, Blowfish implementations assume big endian format, so on little endian platforms, you have to flip them before processing.

I'll take care of those errata in the docs, thanks for pointing them out.

[brianmount]

Basic drawing is now functional on the iPhone. I have a question about the clipping modes. Apple's drawing environment basically supports only AND mode, where the new clipping area is intersected with the existing one. To open up the clipping area, you have to pop the graphics state. So to support RIVA's various modes, I will have to manage the clipping areas using my own internal stack, apply the current clipping area when called for, and pop it off when the operation is done. I can certainly do that if I have to.

But I have noticed that the commands sent out by the server only use the COPY mode when there's no existing clipping area, and the AND mode otherwise, which means that my code works just fine by ignoring the mode entirely (the graphics state starts with a default clipping area of the entire window, so COPY and AND are the same thing when starting out). Does the server ever use other modes, or use the COPY mode to replace an existing clipping path? Or is this future functionality that I can ignore for now, as I am doing with the text mix mode? Thanks.

[Dean Roddey]

Curently, yeh, that's the case. It could use the other modes but currently doesn't. So, I'd plan for it, but to get to the first implementation, it won't be necessary. So just architect with the understanding that this could be required later, so that you are prepared.

[brianmount]

I have identified what I think may be a problem in CQC. My iPhone RIVA client works fine, buttons get pressed, etc. But when I disconnect, something (at port 13505) goes down in the CQC processplex, and subsequent connection attempts are rejected until the service is restarted.

First off, I think I am currently failing to send a proper LogOff command. I need to sort out my state logic and fix the problem. But even if the CQC problem is triggered by failure to receive a LogOff, I'd think you'd want to fix CQC not to have this vulnerability (if indeed there is one).

We have an instance of the variables driver containing a single string variable, and a template with two buttons that stuff different values into that variable and a text box that displays the variable value. Press one button, see the first string. Press the other button, see the other string replace the first. And so on.

When I disconnect, the log says:

The remote client at endpoint 192.168.1.127:52397 dropped the connection (worker thread 15)

(because I didn't send a LogOff).

If I have not pressed either of the buttons, all is well. I can reconnect and see the template again. But if I have pressed one of the buttons, then when I try to reconnect I get this error in the log:

An exception occurred in worker thread 9

and my connection fails. Subsequent connections fail with the generation of the following pair of errors:

The server at 192.168.1.137:13505 was not available
An exception occurred in worker thread 9

It looks to me like maybe the variables driver, or some component like that, is dying. It's always port 13505 that is mentioned as being unavailable. Maybe you will just know immediately what part of CQC that is.

When I restart the CQC service from the control panel, things return to normal, and I can once again connect and see the template, until the next time I disconnect after having pressed a button, at which point the problem happens again.

Let me know if you need any more information about this. Thanks.

Brian

[Dean Roddey]

That's the data server. That's something that will be running on the master server and will be called CQCDataSrv, so check the master server and see if that's running. I'm sure it will be, so there has to be something else going on.

[Mark Stega]

I just talked to Sergio and he is having a similar problem. I asked him to get the system into the failed state and run a CQCNetTest and send it in to us. Apparently it happened quite a few times yesterday.

[SamVimes2]

It happens repeatably for me too

[Dean Roddey]

Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server.

But it's strange that the other clients aren't seeing this program. Something odd has to be going on there that's specific to this client, but what it is I'm kind of at a loss to say. I guess we could try just killing the .Net or C++ client via the task list to simulate a non-graceful shutdown and see if that replicates the issue.

[jkish]

Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server.

But it's strange that the other clients aren't seeing this program. Something odd has to be going on there that's specific to this client, but what it is I'm kind of at a loss to say. I guess we could try just killing the .Net or C++ client via the task list to simulate a non-graceful shutdown and see if that replicates the issue.

I have some random issues that seem to involve the data server.

Every few days, I find the IV locked up and have to reboot the machine. I don't know what triggers it, but in the logs I always find something about not being able to contact the data server.

[Dean Roddey]

That's new to me. No one ever said anything so I've had no reason to look into it. Are you taking about the regular IV here?

[jkish]

That's new to me. No one ever said anything so I've had no reason to look into it. Are you taking about the regular IV here?

Yes, just a regular IV.

I haven't mentioned it before since it has been sort of random, I couldn't pinpoint anything that might have led to the problem, and I couldn't rule out something in my environment that might be sick.

But hearing another mention of the data server possibly having problems made me think that it could be related.

[VidaBox LLC]

I have also been able to get the RIVA client you developed Dean to eventually chokes and not be able to log on. It takes a couple of tries and eventually, it won't log on. CQC server reboot is the only solution. I'll check into it some more the next time it happens with what you suggested.

It's funny but I haven't had any issues with it today so haven't been able to look into it more deeply.

[brianmount]

It happens repeatably for me. Is this CQCNetTest thing something I can run? Would it help you to check if something's wrong? How do I do it?

[Mark Stega]

Open a CQC Command prompt (it is a shortcut created when you installed CQC). At the command prompt type "CQCNetTest >z.tmp" (leave off the quotes). Post the content of z.tmp here.

[Edit] Do this when you are in 'broken' state

[SamVimes2]

I got into the broken state:
http://img42.imageshack.us/img42/7839/dataserver.jpg (http://img42.imageshack.us/i/dataserver.jpg/)

but I don't see anything obviously wrong in my net test:

CQC Network Info Test
Copyright (c) Charmed Quark Systems


System Information
--------------------------------
OS Version: 5.2.2, Build: 3790
Node Name: odin
TCP Version: 2.2


Network Adaptor Information
--------------------------------
{ACE2EEF0-252A-4BB9-92FE-DA98AA97A97F}
Generic Marvell Yukon 88E8056 based Ethernet Controller
DHCP Enabled: True
Gateway/Mask: 192.168.0.1/0.0.0.0
Hardware Addr:
Address/Mask #0: 192.168.0.186/255.255.255.0


Environment Information
--------------------------------
CID_NSADDR: odin
CQC_DATADIR: C:\Program Files\CQC\CQCData


Name Resolution
--------------------------------
Trying to resolve name: odin...
Resolved to: 192.168.0.186

Resolving back the other way...
Host Name: odin


CQC Connection Tests
--------------------------------
Trying to connect to CQC name server...
Connected to name server successfully

Trying to connect to log server...
Connected to log server successfully

Trying to connect to Master Cfg Server...
Connected to Master Cfg Server successfully

Trying to connect to local Cfg Server...
Connected to local Cfg Server successfully

Trying to connect to installation server...
Connected installation interface successfully

Trying to connect to security server...
Connected security interface successfully

Trying to connect to macro server...
Connected macro interface successfully

Trying to connect to CQCServer on host odin
Connected CQCServer successfully


Server Statistics
--------------------------------

Stats For Process: Name Server
----------------------------
Object Id: odin.13502
Running On: odin
Up Since: Tue, Sep 29 18:33:12 2009 -0400
Client HWM: 16
Dropped Packets: 0
Cur Clients: 11
Max Clients: 92
Active Cmds: 1
Queued Cmds: 0
Registered Objs: 2
Worker Threads: 4
Targets: 0
Cmd Cache Sz: 0
Srv Cache Sz: 0
Wait List: 0


Stats For Process: Log Server
----------------------------
Object Id: odin.13503
Running On: odin
Up Since: Tue, Sep 29 18:33:12 2009 -0400
Client HWM: 13
Dropped Packets: 0
Cur Clients: 12
Max Clients: 92
Active Cmds: 1
Queued Cmds: 0
Registered Objs: 2
Worker Threads: 4
Targets: 0
Cmd Cache Sz: 1
Srv Cache Sz: 1
Wait List: 0


Stats For Process: Master Cfg Server
----------------------------
Object Id: odin.13504
Running On: odin
Up Since: Tue, Sep 29 18:33:12 2009 -0400
Client HWM: 3
Dropped Packets: 0
Cur Clients: 1
Max Clients: 92
Active Cmds: 1
Queued Cmds: 0
Registered Objs: 2
Worker Threads: 4
Targets: 1
Cmd Cache Sz: 2
Srv Cache Sz: 1
Wait List: 0


Stats For Process: Data Server
----------------------------
Object Id: odin.13505
Running On: odin
Up Since: Tue, Sep 29 18:33:16 2009 -0400
Client HWM: 4
Dropped Packets: 0
Cur Clients: 1
Max Clients: 92
Active Cmds: 1
Queued Cmds: 0
Registered Objs: 6
Worker Threads: 4
Targets: 1
Cmd Cache Sz: 2
Srv Cache Sz: 1
Wait List: 0


Stats For Process: CQCServer on odin
----------------------------
Object Id: odin.13507
Running On: odin
Up Since: Tue, Sep 29 18:33:19 2009 -0400
Client HWM: 7
Dropped Packets: 0
Cur Clients: 6
Max Clients: 92
Active Cmds: 1
Queued Cmds: 0
Registered Objs: 2
Worker Threads: 4
Targets: 1
Cmd Cache Sz: 2
Srv Cache Sz: 1
Wait List: 0

[SamVimes2]

Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server.


This worked for me - after I got in the broken state (see above) I killed the CQCRemVSrv.exe process. It restarted automatically and I could connect again. No reboot/service restart required.

Now all we have to do is figure out why it happens in the first place!

[Dean Roddey]

OK, that makes more sense. It's the RIVA server getting wierd, not the system in general. I'll take a look at that after get the next drop out in a couple days. And this happens when you just kill the connection, right?

[brianmount]

Yes. I don't yet know whether it will happen when I send a LogOff, because I haven't gotten that part of my application done yet.

[brianmount]

Hmmm. I figured that my LogOff message was not getting through, because I was seeing the CQC log message indicating that my client dropped the connection, and the RIVA documentation talked about the LogOff being a way to avoid log warnings about communication failures. But I modified my program to wait explicitly after sending the LogOff, to make sure that it got sent before the socket was closed. And still I see the dropped connection message. Should I expect the log to look different, or is that message always logged regardless of whether LogOff is received before the connection is closed?

[Dean Roddey]

Maybe there's something not totally correct there on my side to look for the Logoff as it's supposed to. I'll have to look into that.

BTW, you use the 'linger' option on the socket, which will keep it open long enough to make sure the other side sees the sent data after you close it.

[brianmount]

The documentation states that only some of the bitmap modes are currently used. Can you tell me which ones? I am trying to work out which of Apple's transfer modes correspond to which of CQC's, and it's not immediately clear. So I want to make sure that at least I come up with satisfactory mappings for the modes that are actually used.

What is the difference between srcCopy and patCopy? Some of the references I see indicate that patCopy uses the current brush, ignoring the source image. Is that true? Likewise, does dstInvert invert the destination, ignoring the source image?

[Mark Stega]

Brian,

I'll let Dean deal with the transfer modes. As a note, I started and built up a 90% working client using the full protocol. I never got some subtleties like text reflection, etc. to work well. I also ran into the fact that the .Net Compact Framework did not support the alpha channel in images. We worked out the simple protocol and I was able to do away with all of the issues relating to things like you are dealing with and the resulting viewer is blazing fast even with the transfer at times of complete screen size bitmaps. If you want a quick time to first version I'd recommend you start with the simple protocol and then work on implementing the full. The full protocol might be better at 3G speeds but certainly on WiFi the simple protocol is more than adequate.

[Dean Roddey]

Mark's idea might be worth looking into. But, anyway, in the meantime the answer to your question is, just do src copy for now. I don't think that any other mode is used other than in the context of masking images for transparency color (which you'd do on your side internally), or in some cases like the progress bar or the CAB's fancy cover art displays, neither of which the RIVA protocol supports currently.

As always, leave it open to add support for other modes, but just do source copy for now.

Ultimately, on my side, those calls that use those patterns boil down to calls to the Windows BitBlt() call, which is documented here. It describes the various modes. The names are slightly different but I think that the translation should be obvious. Let me know if not.

http://msdn.microsoft.com/en-us/library/aa930997.aspx

[Dean Roddey]

Well, I'm not seeing anything that could possibly cause the RIVA server not to be able to contact the data server. So, for the moment, I'm going to go ahead and get a new drop out, and we'll just have to dig deeper into this in order to see what's going on. There's some important stuff in this drop to get out so I don't want to hold it up. I've got 5 instances up right now, and I've been interacting with them randomly and logging off and stopping and starting them and it's working fine.

[brianmount]

On a totally unrelated note, I noticed last week that my Logitech Squeezebox Duet system now appears to allow people to write applications for it. I don't know anything about how the development process would work (other than that apps are written in Lua, and there do appear to be networking and graphics libraries), but it did strike me that people with CQC systems and Squeezeboxes would probably love to control one with the other. However, the controller is not a touchscreen device. It has a nice little display on top and a bunch of buttons and clickwheel on the bottom. So I don't immediately see how the RIVA protocol could be used as is, since it expects user interaction to come in the form of press, move and release messages. I guess the Squeezebox client could take the button presses and clickwheel moves and map them into pretend mouse moves to fixed locations on the screen. Then the template would need to be designed to align with those fixed locations. That's a little hokey, though.

[Dean Roddey]

Yeh, that would be a tough fit. It might be better to do something with the XML gateway for something like that.

[potts.mike]

There is a touch screen squeezebox now as well.

[SamVimes2]

Well, I'm not seeing anything that could possibly cause the RIVA server not to be able to contact the data server. So, for the moment, I'm going to go ahead and get a new drop out, and we'll just have to dig deeper into this in order to see what's going on. There's some important stuff in this drop to get out so I don't want to hold it up. I've got 5 instances up right now, and I've been interacting with them randomly and logging off and stopping and starting them and it's working fine.

I am still having this problem all the time - something in RIVA that bugs out that requires me to kill the process.

I realize it may be something on the client end, but this is still not the usual 'bulletproof' CQC experience I like to brag about...

[Dean Roddey]

Yeh, I'll be looking into this. There are just some immediate term things that I'm dealing with first.

[Dean Roddey]

Try out 3.0.12. There was an issue fixed there that could explain all or at least some of your issues. Even if it's only some of them, we want to only spend time looking into the ones that are not dealt with, not the ones that have been.

[Dean Roddey]

Sergio seems to have confirmed that the above fixes took care of the problem where the RIVA server stopped being able to connect. At least he hadn't had a problem by whenever he left it today. So it looks reasonable.

However, there is a wee issue in .12 (documented on the second to last page of the beta thread) that will prevent certain action commands from getting correctly updated and they may fail to be brought forward. So probably best to wait until lucky .13 and then move forward if you haven't already.

[Dean Roddey]

I updated the header to reflect the most recent stuff in 3.0.13 and up. It's mainly the addition of stuff to support embedded RIVA clients being able to map local hard buttons to hot keys that they can send to the server and have them mapped to an action.

[VidaBox LLC]

Sergio seems to have confirmed that the above fixes took care of the problem where the RIVA server stopped being able to connect. At least he hadn't had a problem by whenever he left it today. So it looks reasonable.

However, there is a wee issue in .12 (documented on the second to last page of the beta thread) that will prevent certain action commands from getting correctly updated and they may fail to be brought forward. So probably best to wait until lucky .13 and then move forward if you haven't already.

Yeah! I haven't had this happen again but I haven't extensively tested it recently.

[brianmount]

One slowness we find on the iPhone is when using my friend's template that displays his movie library as a series of DVD cover thumbnails. I think he may be using much larger images that are then scaled down, which would explain the long transfer time. But one way or the other, it takes a disappointingly long time to fetch the image data (of course, it's fast once the images are cached).

Currently, I fetch the images one after the other. I had the thought that by opening multiple parallel connections to the RIVA image server, I might be able to fetch the data that much faster. Does the image server support that sort of thing? If so, what would be a reasonable limit on number of parallel connections by a single client?

[Dean Roddey]

I wouldn't do the multiple connections. Ultimately, if he wants better performance he'll have to deal with the image size. Most of the repositories support small and large cover art, though it depends on which one. The small ones would be used by default, and generally if a separate small one isn't provided then the large one is scaled down to create the thumbnail.

We could of course perhaps add an addition option to allow the server to scale the images for you before tranmission perhaps.

Make sure that 'use large art' isn't checked on the CAB as well!

[SamVimes2]

Make sure that 'use large art' isn't checked on the CAB as well!

Just tried it unchecked. It makes a huge difference! Thanks Dean - that was a lot easier than his other strategy...

[jrunde]

What's the odds of creating a client for Android?

Work just got me a new Droid last week as my HTC touch had died.

[brianmount]

OK, I'll hold off on the parallel image fetches, then. Do you think there is much pickup to be had from using a single connection to fetch all the images, rather than making a new connection for each? I had figured it wouldn't help much, and it would complicate my logic a little, but if you think it would be significant, I can try it.

[Dean Roddey]

Hard to say. I guess it's more to do with the overhead on the iPhone for establishing a connection and breaking it back down. Since it only happens until the images are cached, that would further reduce the benefit for a non-simple mode type client.

[wuench]

On my IPhone using 3g the latency is 500ms 10mi from my house. So you would incur about 3/4 sec latency to get each TCP connection established before you can transmit any data. And 1/2 sec latency for each request/response. Of course at greater distances or on Edge this number would go up.

If you use multiple connections you are going to have to deal with the added latency to establish each connection, (if they are opened serially). On the other hand, if you can only fetch one image at a time on a single connection, then the latency is going to get you that way too.

So things like TCP connection pooling and reusing existing connections might provide optimal results. If you don't want to look into that stuff for this release, i'd be happy to help do an analysis after you release.

[Dean Roddey]

It looks like we missed having an OK key in the list of hot keys. The NEVO has one, and Sergio wants to be able to map that to a hot key with that name, and it'll probably be very common. So I'm going to add an OK hot key. There's no particular reason for existing clients to implement this key at this time. It just means that client will never send it. So I'm not going to bump the protocol version for just this simple change that won't affect existing clients.

But just incorporate it in a subsequent release if it makes sense for your particular platform.

[brianmount]

Looking at the user responses about the iPhone RIVA client, it seems that the speed hasn't been a problem so far. But I do see some complaints that when the connection is broken (either due to a network problem or by the device going to sleep), the client can't pick up where it left off. I can imagine how that would be quite annoying.

Would it be possible for a future revision to the RIVA protocol to include some sort of "mileposting" system, where the server sends a number or ID indicating where in the interface tree the user was, which the client can remember and send back at reconnection time?

This could be something the RIVA server handles itself, by sending the name of each new template as it is loaded, and letting the client send the desired template name at login time.

Or it could be something where the onus is put onto the template maker, with the addition of a special command that templates can use to send a number or ID with the current state, and a RIVA command that clients use to send back that state (in the same way that they send hot keys now). Does that make sense?

[Dean Roddey]

There's no way that would work, because where they are can include multiple levels of nested interfaces and various variables and such, all of which were set up dynamically as things were done.

The only think that would work would be to allow the server to keep going on that session for a while and allow the client to reconnect, which would introduce a lot of complexities as well, but would be at least theoretically possible.

[SamVimes2]

Dean, are GVars retained across logouts/ins for a particular account in RIVA?

[Dean Roddey]

No. They are per session. When you log in, that's just the same as starting up the regular viewer.

[Mark Stega]

Dean, are GVars retained across logouts/ins for a particular account in RIVA? No, each session is a new instance starting fresh, much like a new IV session created by stopping/starting the interface viewer.

[dgeffs]

There's no way that would work, because where they are can include multiple levels of nested interfaces and various variables and such, all of which were set up dynamically as things were done.


I'm one of the complainers and I can really see Dean's point about a user being nested many levels deep with all sorts of things going on. I'm sure that applies to those of us who use overlays almost exclusively which would be pretty hard to track. I guess a programatic solution to this would not be a trivial task.

Based on what I'm hearing this really isn't going to be something that is possible without some major changes. Therefore I think the next best thing for now is to get the client to reconnect automatically and simply load the default template. That would at least get us away from the error message and having to restart manually every time.

The iTouch is a really an inexpensive way to put portable touchscreen interfaces all over the place and with the new Apple Slate product coming this year I think it's easy to see there will be a great demand for all of these items. The iPhone client is a tremendous version 1 product. Just think of the possibilities.

[Dean Roddey]

The most reasonable scenario would be to allow the server to keep a session open in a reattachable way for some short amount of time, so that a temporary loss of connection doesn't destroy the session. But that would require some new functionality in the server and clients.

[dgeffs]

The most reasonable scenario would be to allow the server to keep a session open in a reattachable way for some short amount of time, so that a temporary loss of connection doesn't destroy the session. But that would require some new functionality in the server and clients.

It's the short amount of time that I'm worried about. Peoples definition of short will be all over the place. I'd need the connection to stay active for at least an hour.

[Dean Roddey]

But if the network connection is down for an hour, it's irrelevant what we do, since you couldn't be doing anything while the network connection is lost. I think that the main issue is that the network connectively blinks out for four or five seconds and that causes the socket connection to be dropped between the client and server. This happens at a level below what we can control.

But, if we allowed for some way for the client, after loss of connection, to try to reconnect to the same session on the server, which it would keep open for, say, 15 seconds worst case before giving up, that would allow the client to reconnect to that same sessiona again after an intermittent wireless network failure. The server would just completely redraw the screen to make the client get back into sync again where it was before.

That's something that's probably reasonably doable and I think it would address most problems. So you might get periodic 'please wait' type of dialog boxes as its trying to get reconnected again when the connection is lost. But it would come back to where it was, as long as it can reconnect in some fairly short time.

[brianmount]

Do I understand your suggestion to be that when the client logs in it receives a session token of some kind, and then later on, when logging in again after a dropped connection, the client can pass that token and "claim" the session again? That sounds like a good idea.

[brianmount]

We were talking about the leading/trailing space issue on the iPhone client thread, but perhaps it belongs more properly in this thread. I'm not sure it's really right to count all whitespace when breaking lines and centering. Let's say that the user's multiline text string consists of 44 characters: a space, an A, 40 spaces, a B and a space. The text box is narrow enough that my RIVA client decides to break up the A and B onto separate lines. When center- or right-justifying the text, which characters should the client count as part of each line?

[Dean Roddey]

Do I understand your suggestion to be that when the client logs in it receives a session token of some kind, and then later on, when logging in again after a dropped connection, the client can pass that token and "claim" the session again? That sounds like a good idea.

Yeh, something along those lines. It would stay open for a while on the back end. Not a long time, but long enough that short losses of connection would cause a reset. If you try the relogin and it fails (probably with a 'bad session id' if it's been too long), then you'd go back to scratch with a regular login (though those two things could be done in one call really, if you get back a 'bad session id' but the login info is good, you'll get back a new session id and that becomes the active one. Doesn't matter per se to you which happened. You would just flush any stacks since when you connect you'll just get a full redraw.

[Dean Roddey]

Breakage, I would think, would always be at the first space after the last thing on the first line, on any platform, right? If so, then those other spaces would be relevant on the second line for left or center justification. They would effectively do nothing for right justification since they wouldn't affect how it's position (being to the left of the text.)

Ultimately, underneath a number of nested hoods, I use the Windows text drawing stuff, so however it handles justification in multi-lines is how it should be done, in order to be consistent. I'm guessing most platforms would tend to do it kind of the same.

[brianmount]

But if you had the string "A A", and broke it on two lines, you'd expect the two A's to line up no matter what justification you use, correct? If we left the space as part of the second line, they would not line up for left- and center-justification. I'm pretty sure we ought to excise the space in this case.

In this application I'm doing my own word breaking and alignment (Apple's version works a little differently from Windows in certain ways, so I had to roll my own). So I need to figure out what rules to use. I guess I'll just keep changing the rules until people stop complaining.

[Dean Roddey]

You can quickly check what should happen using the Interface Designer. Create a static text, set the justification, allow word wrap, and then start pushing spaces between two A's with centering. I think it will keep the spaces but maybe it reduces them down to a single breaking space, I've honestly not really looked at that in detail for a long time.

[brianmount]

How does the PlayWAV command work? I see that, when Rob puts a sound in his template, and I trigger it, I receive the string "C:\Windows\System32\8point1.wav". I'm assuming that I pass the string back to the image server to fetch the data, but I'm unclear on the details. Is there a prefix to be added to the string (akin to CQCRepo::), effectively creating a third data cache? Or am I totally off base with the image server concept? Thanks.

[Dean Roddey]

There's no third cache or anything. My thinking would be that they would just arrange to have the sounds desired on the target device and provide the RIVA client a simple path mapping (e.g. C:\MyWAVs\ becomes /CQCWAVS/ or something like that) to map from the path they provide to wherever they put them on the client.

Some of these files are large, so we can't transmit them every time, and I'm kind of loath to introduce another cache. And also the RIVA server may not be running on the machine where the WAVs are either.

If it is deemed just not workable to do it this way, we can consider another cache. But hopefully we can avoid it.

[brianmount]

Hmmm. But how would a template designer get their sound files onto the iPhone? I don't think that's workable in the heavily regulated iPhone environment, where each application has its own sandbox file system. And I bet that many mobile and small-footprint devices will have a similar problem. Smartphone users aren't usually provided with a file explorer application. Maybe Android will be able to do this, but nobody else.

Further, any new client would need to be configured before use. If Rob's iPhone-loving friend comes over to his apartment, and Rob wants to show him his cool iPhone-controlled CQC system, he can't just give him the host, port, user name and password to put into the phone. He also has to load up the necessary sound files. No other aspect of RIVA currently requires this -- images, for instance, are pulled from the server as needed.

Perhaps I'm missing some clever approach; let me know if you have any suggestions. But it seems problematic. You note that the RIVA server may not be running on the same machine where the sound files are. But that is also the case with images, correct? Maybe you're imagining the WAV file being used to retrieve songs, large audio files, etc. that would reside on a separate A/V machine. I can see how that might be a problem. I was envisioning things more like system alert sounds, beeps and clicks, things to make the user interface nicer.

So I heavily favor the creation of a third cache of opaque data that the image server serves from in response to appropriate request paths. This would let me use sounds on the iPhone. And I may also be able to use the same mechanism for font downloads: when the client gets a request for a font it doesn't recognize, it asks the image server for Opaque::Fonts/TheFontName or some such, then installs the font locally. Just a thought.

[Dean Roddey]

I guess I was kind of looking at it more from the perspective that some (potentially important) RIVA clients might not have any such ability to do this but would have ways to make simple sounds built into them. In that case, you would set up the RIVA specific templates not to point to actual paths, but to just use some identifying keyword. They don't actually have to be paths per se.

Those would then be used to trigger available built in sounds on the target device. I was thinking of like set top boxes in the future and things like that, or some these smarter remote controls that are showing up.

The way it has worked in the past is that it's assumed that the thing to play back will be availble on the client where the playback occurs. The path is interpreted as a local path. For instance, the back end may be a Windows Server machine that doesn't have the same files as the Vista/Win7 clients do, so it couldn't serve them up without having to move those files to the server.

So it's kind of tricky either way.

[brianmount]

Got it. So it's not necessarily even a WAV-format file at all that's being played, correct? We could use whatever format we wanted.

[znelbok]

What are the ports that are used for the RIVA client/server?

I can find reference to 13505, but I remember that there was a second port listed during install.

Is there anywhere that I can find all default ports used by CQC (documentation etc).

Mick

[Dean Roddey]

Got it. So it's not necessarily even a WAV-format file at all that's being played, correct? We could use whatever format we wanted.

Yeh, that's what I was assuming. And that in some cases the client itself isn't playng anything but just asking the OS to make some pre-defined sound or something.

[Dean Roddey]

It will be the next port up from that, 13506, unless you changed it.

[SamVimes2]

Dean,

If I have a template with an overlay, and a RIVA client sends a hotkey, which template's action gets triggered?

[Dean Roddey]

At whatever level is the top level template (i.e. base or topmost popup) it will search any overlays in z-order. The first one that provides a handler will get invoked and then we are done.

If no overlay handles it, the underlying parent template is checked. If it provides a handler, then that is run. If it doesn't but it provides an Otherwise type handler, then that is run. If there is no otherwise, then nothing is done.

The otherwise is never checked in the overlays, that's only checked at the base template level, otherwise, nothing could ever propogate beyond the first overlay.

[anogee]

I don't want to change the flow of this but I'm wondering, is a Mac RIVA client available yet? How about a PC? When I last checked, the answer was kinda but not really. If so, do you have links?

[Dean Roddey]

There's not a Mac one. There's one for XP, eXP, Vista, etc... It comes with the product. You have to enable the RIVA server and client during installation of course.

[potts.mike]

As far as mac goes I thought I remembered some one compiling the .net viewer using mono and running it on the nokia tablets. If this can be done then there really is no reason that it could not be compiled using mono on a mac and have it work. I took a look at it but realized I was hopelessly lost

[sic0048]

I'm not sure anyone actually compiled it in Mono. If I remember correctly, it was more a conversation of "what if" rather than real implimentation.

I'd love to see some solution that works specifically on the Nokia tablets. I have several and they make great IVs. But using RDP on them really prevents them from going mainstream. It's just too problematic right now to expect them to work without any connection issues. (It works fine for me making the RDP connection and then using them out by the pool or something like that for the day. But you cannot rely of them 24/7 using RDP).

[potts.mike]

http://www.charmedquark.com/vb_forum/showpost.php?p=109333&postcount=268

[anogee]

It comes with the product. You have to enable the RIVA server and client during installation of course.

Hmmm.. The "product?" :-D
I installed it all on my Master Server, but don't see it in the program list. I know the server is install because my iPod connects fine. I do see something called CQCRPortClient_3_0.dll but no exe. Am I close?

I want to install it at work, so I'm not sure the install will run there.

Yeah, I do remember seeing the Mac version, but as you say, not really finished.

I wonder if a RIVA to HTML converter would ever be possible?

[Dean Roddey]

If you look in the Start Menu, there should be a Remote Viewer Client. At work, do a standalone remote viewer mode install. All it will install is the remote viewer client and no services or anything.

[anogee]

O.K. Great. Thanks.

[wuench]

I think I found another issue. Popups when programmed to go to -1,-1 on both the Iphone RIVA and Windows Riva client render off screen, up and to the left. On the IV this is centered. I want to say they are rendering the bottom right corner at the center of the screen.

[znelbok]

Are the ports used for the RIVA client connection TCP or UDP or a combination of both?

Mick

[Dean Roddey]

They are TCP.

[Dean Roddey]

I think I found another issue. Popups when programmed to go to -1,-1 on both the Iphone RIVA and Windows Riva client render off screen, up and to the left. On the IV this is centered. I want to say they are rendering the bottom right corner at the center of the screen.

All my popups are set up with the default positioning and they all show up correctly centered for me. Maybe it only happens with the device is smaller than the templates or something? They will center relative to the template, not to the window. But, if that would put them off the window area, they'll be forced back visible again if possible.

[wuench]

Ah, ok. I am doing it from a little menu popup in the top left and the new popup is triggered from there. So it looks like it is centering the popup over the center of the menu, but half of the popup is off screen. The second popup is less than the screen size, it isn't being forced back onscreen on either RIVA client.

I guess I will need to hard code coordinates for those, that's gonna be a pain. It seems more intuitive to me to have the popup coordinates relative to the screen vs. the calling template, or at least to have an option to center it to the screen.

[Dean Roddey]

I updated the beta website docs and added a RIVA User Guide technical document, to just discuss the general RIVA system and how it works from a non-developer point of view. It's not quite as coherent as it could be in this first cut, but it's a start.

[brianmount]

Dean,

I have some questions about the StartDraw and EndDraw commands. More important is the EndDraw question. I think I may be misunderstanding how to process it. The message indicates the portion of the screen to be updated. Straightforward enough. But then what do I do with my offscreen buffer. Am I supposed to dump it completely? When the next drawing cycle begins, will the server start from the ground up and tell me everything I need to know again?

I had been assuming that I needed to keep the offscreen buffer around, and then apply the new drawing commands on top of the existing buffer, but I'm seeing glitches in the rendering, and I think maybe it's because my assumption is wrong. Let me know if I'm not explaining myself properly.

Regarding StartDraw, I have noticed that sometimes I get some drawing commands, then StartDraw, then more drawing commands, then EndDraw. In other words, the StartDraw is not the first message in a new packet of updates. Is that to be expected? The documentation implies that I would get StartDraw first, but maybe that's not always the case. Right now I ignore StartDraw, so it doesn't matter, but if I have to rework my logic for EndDraw, the StartDraw may become important.

Thanks.

[Dean Roddey]

You should always get start draw first. Are you always checking the packet sequence numbers to insure you aren't missing packets? If not, you may be missing some which could explain the gitches.

There's generally nothing particular you need to do on StartDraw. It's just to tell the client that if it has anything it needs to reset for a new drawing cycle, it should do so.

On the EndDraw, you just need to blit from the memory buffer to the screen. Whether you keep the memory buffer around or not platform specific. Windows requires that I redraw the screen any time something is uncovered, so I have to keep around what's been drawn in order to update the screen. You may not need that if your platform maintains the window contents for you.

BTW, if you aren't up to .36, and you have any OnTimeout events set in any templates, then you could get intermixed start/end cycles. There was an error that was not serializing those events into the larger stream of stuff, so you could get one starting in the middle of another cycle. So that might explain some issues.

[brianmount]

I was thinking about doing some persistent image caching. Are the serial numbers sent by the Riva server persistent? If the CQC environment is stopped and restarted, or even reinstalled and restarted, will the serial numbers be reset, or do they persist? If a user removes an images, then adds a new one with the same path, will the serial number be reset?

[Dean Roddey]

The serial numbers are transient. They are just for runtime purposes. You could always make it an option, where they can indicate that they only want to you get new images if they force it, if they know the images will not be changing. You can provide a menu option to clear the cache.

[wuench]

Can't you provide a mechanism to indicate if an image timestamp or something? So clients automatically know if an image has changed and can download the updated image.

Given the requirements for this type of app, you really need to put in some of these featuresj to accomodate high latency and transient connection. But I am glad Brian is considering persistent images.

I was just demoing my screen to a guy at work and it went like this...

Ok this screen... wait for it... it takes a little while over 3g, ok there this is my flooplan, now if you click here.... ok wait for it... here is my security keypad, and I can control my thermostat... wait.... (you get the idea).

[Dean Roddey]

We can look into something like this after 3.1. It would be way too big a change to do before then.

[IVB]

dumb question but i was up until 1:30am putzing with my S70 screens and didn't have the energy to check:

Do fonts have to be natively installed on the device with this? If so, sergio, any clue on how to install new fonts on the S70?

[SamVimes2]

Something that would be nice for the iPhone at least, on which the user can't add any new fonts, would be a way for the client to request font data though the existing image cache, or even a new 'font cache'...

[brianmount]

I have a question about an aspect of RIVA that I haven't quite figured out how to handle. As far as I can tell, there is never an indication of how large the template is, nor when a new template is loaded. So what I have done is set the initial size of the scrollable content area equal to the screen size, increasing it whenever I get an EndDraw whose rectangle includes additional real estate. This works pretty well to size the content size automatically. Then, if the content size is larger than the screen, the user can scroll around as needed.

When the user loads a new template with a smaller size, the content size ought in theory to shrink down to that area. But my client doesn't realize that a template switch has taken place, so what happens instead is that the full size of the old template sticks around in the client's understanding, messing up the size of the scrolling area.

For instance, on the iPhone, you can rotate the device. What Rob has done is create a 320x480 portrait template and a 480x320 landscape template, switching between them when the client signals that the device has changed its orientation. But since the client doesn't realize that the template has changed, I wind up with a 480x480 content size, with unnecessary extra scrolling area either below or to the right of the real template.

I thought about resetting the content area size when the device is rotated, but that has its own problems, and wouldn't help in the simple case of a smaller template replacing a larger one. And I'm planning to allow the user to disable scrolling altogether, which will help Rob, but won't help in any situation where the template is bigger than the screen size, and some scrolling is required.

Is there in fact a way to detect, either officially or via heuristic examination of the RIVA command flow, that the template size has changed? If not, do you have any suggestions on how I should attack this problem?

[Dean Roddey]

Something that would be nice for the iPhone at least, on which the user can't add any new fonts, would be a way for the client to request font data though the existing image cache, or even a new 'font cache'...

How would you actually make use of them though? You are going to get a raw TT type font file. Unless you have some way of installing them from within the RIVA client program, it wouldn't really help.

[Dean Roddey]

Is there in fact a way to detect, either officially or via heuristic examination of the RIVA command flow, that the template size has changed? If not, do you have any suggestions on how I should attack this problem?

We can always add a new message in the next version of the protocol that will send you the name of a newly loaded base template and the size of it, and maybe some other info if that's useful.

[SamVimes2]

How would you actually make use of them though? You are going to get a raw TT type font file. Unless you have some way of installing them from within the RIVA client program, it wouldn't really help.

the iPhone SDK has methods that can load and render a truetype font in an app:
http://www.waterworld.com.hk/en/node/157

i'd be pretty surprised if the .net cf and android platforms didn't have similar methods, but you should let an expert weigh in.

[Dean Roddey]

But if it couldn't actually install them, then it would have to download that information every time it ran. TTF fonts are usually from 100K up to 1MB or so. That probably wouldn't be very practical, would it? That would be way larger than the template data itself, up to ten times larger.

[SamVimes2]

But if it couldn't actually install them, then it would have to download that information every time it ran. TTF fonts are usually from 100K up to 1MB or so. That probably wouldn't be very practical, would it? That would be way larger than the template data itself, up to ten times larger.

I just meant that users can't install fonts in the same way they (sometimes) can on a windows CE device - the joy of an apple product! Apps are free to store and consume whatever resources they want (within some other appl-y limits obviously).

The transport font that a lot of us use is only 17k, and would save much more than that in image downloading. in addition, hopefully the same cross-session image-caching stuff you'll hopefully think about for 3.2 would extend to fonts, and even a larger one could be downloaded just once.

now, looking more closely at the license of this particular font, it seems possible they would give us permission to use the font as a resource in the app. but IVB asked the same question about a totally different platform; seems like this will come up enough to warrant some though about a more general solution

[Fonceur]

I've been distracted by other projects, so things are going slower than expected... When I tried to port the MessagePacket.cs from the .NET RIVA client, I realized that the Android platform doesn't have any unsigned integer/byte, as it is java based... So the question is, do I have to waste memory going uint16 --> int32, or would the values actually fit in uint16 --> int16? I know that for the byte I don't have a choice, with values like 0xF1...

[potts.mike]

Did the web image widget ever get integrated into the RIVA protocol? I'm working templates for the iPad and they are needed for the squeeze center driver.

[Dean Roddey]

Did the web image widget ever get integrated into the RIVA protocol? I'm working templates for the iPad and they are needed for the squeeze center driver.

No, that would require huge changes because it's really just completely out of sync with the way that RIVA works, and would require substantial changes in the clients as well to support it.

[SamVimes2]

It hasn't yet. Dean has indicated the 3.3 timeframe. JKish has also suggested he's working on some updates to his templates so between these two items I've been holding off on serious SC iPad template work.

[SamVimes2]

Dean, do you mean web widgets or web image widgets? Based on this post (http://www.charmedquark.com/vb_forum/showpost.php?p=119891&postcount=146) and some other discussions I'd been looking forward to web image widgets in the advanced RIVA protocol.

[Dean Roddey]

Dean, do you mean web widgets or web image widgets? Based on this post (http://www.charmedquark.com/vb_forum/showpost.php?p=119891&postcount=146) and some other discussions I'd been looking forward to web image widgets in the advanced RIVA protocol.

Oh, sorry, I thought he meant web browser widgets. Yeh, for web image widgets, that's doable. It just needs a V2 of the protocol. The problem of course is that I don't want to dribble out V2, V3, V4, etc... by adding a thing at a time and having all these backwards versions to deal with. So I need the time to sit down and deal with a substantial chunk of the stuff that has been discussed and do a serious V2.

[SamVimes2]

We need some less confusing names for the pair! Looking forward to V2.

[potts.mike]

If I go ahead and use templates with web image widgets will they just load with the widget missing?

[Dean Roddey]

If I go ahead and use templates with web image widgets will they just load with the widget missing?

Yeh, you just won't see them. Though the iPhone client may get a draw request with an empty URL, which hopefully won't confuse it.

[brianmount]

I think I need more information about the bitmap modes used in the DrawBitmap message. In the version of cqc.h I have, modes 1 through 7 are defined. Most of the time the server sends me mode 5 (SrcCopy), which makes sense. But I also get mode 1 (DstInvert) sometimes. What am I supposed to do in that case?

Also, I occasionally see modes 0, 53, 97, 101, 102, 105 and 114. Maybe there's a bug in my code, but as far as I can tell that's what the server is sending me. Are those defined modes? Or am I supposed to be applying some sort of mask to the bitmap mode byte?

[Dean Roddey]

Oh, maybe there's an issue. The DrawBitmapMasked operation is being passed as a regular DrawBitmap command, but the mode doesn't get set, nor does the transparency color get passed along. I think that we need a new DrawBitmapMasked command to support that. You will have to mask the image using the passed transparent color and display the masked image (the standard sprite type of masked bitmap draw.)

Do any of these problematic ones have images with color based transparency, as apposed to alpha type transparency?

[brianmount]

I will have to let Mr. Vimes answer that. Rob, what are the file formats of your images of the monitors, speakers, printer and so on?

Dean, What is the meaning of the DstInvert bitmap mode? What am I supposed to do when I receive this mode? Maybe in this case I should be receiving it at all, but at least I'd like my client to do the correct thing when I get it.

Also, what happens when the .Net RIVA client gets such invalid modes? I would have expected that the .Net client would show Rob's template in a messed-up way as well, since it would also get the crazy mode values (Rob, have you tried that?). But maybe it does something special.

[brianmount]

On another topic, my client is apparently displaying some of the characters taken from the GuiFX Transports font using the wrong color. In one example, Rob intends the transport controls to be white, but they show up as black. In the debugger, it does appear that the last text foreground color sent by the CQC server was black, which explains why I draw it that way. But I wonder if maybe my text color logic is wrong. All I do currently is rememember the most recently specified foreground and background colors, and use those when drawing text. Is it more complicated than that? Do other commands such as setting the font, drawing text (or non-text), or pushing and popping the graphics state need to be taken into account? Is there a stack of text color settings in any way?

[Dean Roddey]

The pushing and popping of the state should definitely include those colors. All graphics state stuff should be included in the overall state push/pop, including clipping areas and such. DstInvert does a XOR of the colors of the destination area. I don't think that you should be legitimately getting that. I'm hoping that it's the thing above, where you are actually getting some random stuff there. That would certainly explain why some folks are having problems and most aren't. Most folks probably aren't using any color based transparency.

[brianmount]

Is there a parameter that determines the amount of blur applied to the text in the DrawTextFX message? I saw a field called passes or something like that, but I wasn't sure. If there is a parameter, what values does it take on, and how much blur results from the various settings?

[Dean Roddey]

Is there a parameter that determines the amount of blur applied to the text in the DrawTextFX message? I saw a field called passes or something like that, but I wasn't sure. If there is a parameter, what values does it take on, and how much blur results from the various settings?

You will probably end up having to just work it out by eye, because various algorithms will create more or less dense blurs with the same parameters. Gaussian blurs have 'orders' which control how much blurring they do, basically how many taps in the filter. In my gaussian blur code I have two 'fast' orders which are used to do rougher but reasonable quality blurring quickly. One does a smaller amount than the other. For any font size less than 20, I use the smaller one, else I use the larger one. And that really was just done by eye to get some reasonable result.

I would imagine that, if you have some blur algorithm, thorugh up a few sizes of text and make a similar break point on 20 points where you use a little less on things below that and a little more above, and just tweak until you get similar results.

The 'passes' parameter applies the blur that many times, to create a particular density of blur. For now, it's always going to be the same thing I believe and you can safely ignore it. I think that you will find it's always set to zero, which in my world lets the DrawTextFX command make it's own choice and it just sets it to two passes. You can just play around with whichever blur algorithm you choose to figure out what provides basically the same density of blur as what the regular viewer is providing.

[brianmount]

Can you give a little more detail about the note in the protocol specification about needing to decrease the bounding rectangle before drawing blurred text to avoid clipping? Am I supposed to change the font size as well? Are the suggested insets independent of the font size?

Regarding the odd bitmap modes, I don't know what the graphic format is. Rob forwarded me the files as they exist on the CQC server, but my graphics program isn't able to decipher them. The server must be prepending some sort of data to the file or something. And Rob doesn't think he has the originals any longer. If we send you the CQC-ified files, would that enable you to tell what the format is?

[Dean Roddey]

Can you give a little more detail about the note in the protocol specification about needing to decrease the bounding rectangle before drawing blurred text to avoid clipping? Am I supposed to change the font size as well? Are the suggested insets independent of the font size?

You don't need to change the font size. But, the bounding area of the widget shouldn't be drawn outside of. So if you are blurring by, say, 4 pixels, you'll have to adjust the left/right or top/bottom position by that much to correctly justify the text against that edge, since now the edge of the blur is the edge of the text, not the edge of the text itself.

It's somewhat of a by eye adjustment.

Regarding the odd bitmap modes, I don't know what the graphic format is. Rob forwarded me the files as they exist on the CQC server, but my graphics program isn't able to decipher them. The server must be prepending some sort of data to the file or something. And Rob doesn't think he has the originals any longer. If we send you the CQC-ified files, would that enable you to tell what the format is?

The test will be, are you getting any DrawBitmapMasked commands. That only happens when color based transparency is used, and that's the one that's not really being done right.

[brianmount]

Maybe I misunderstood. I was thinking that my client was supposed to adjust the bounds. Is that right? Or do you just mean that the user, when designing the interface, should leave more space around the text? If the latter, then I don't need to worry about it. But if the RIVA client software does the adjustment, is it the case that I take the bounding box passed in the DrawTextFX command and shrink it down before drawing?

[Dean Roddey]

Maybe I misunderstood. I was thinking that my client was supposed to adjust the bounds. Is that right? Or do you just mean that the user, when designing the interface, should leave more space around the text? If the latter, then I don't need to worry about it. But if the RIVA client software does the adjustment, is it the case that I take the bounding box passed in the DrawTextFX command and shrink it down before drawing?

The RIVA client would need to do it. It's not so much shrinking the bounding box, but shrinking the area that you do the justification within. The bounding area (if you mean the area the output is clipped to) would still be the overall widget area. But you just want to, during justification of the text within that area, adjust for the fact that the text is going to be three or four'ish pixels larger than the actual text after it's blurred, so you need to account for that.

So, you might take the original drawing area, and create another one with the sides imploded in by a few pixels (however much your blur ends up being) and use that for the actual calculation of the text for justification and wrapping purposes, but then use the original area for the clipping of the output. And of course when doing a drop shadow, the offset of the text drawn over the shadow would be relative to that inward adjusted position as well.

Does that make sense? I could send you my code for that, though I'm not sure it would make sense (given that I find it complicated and I wrote it :-) But I ultimately came up with a pretty sensible scheme to deal with the blurring and reflection and the positioning thereof and the horz/vertical offset values. Sometimes it treats the blur or the drop reflection as the text and the real text as the thing to offset and sometimes the other way around, depending on which thing would be the part that's up against the edge being justified against.

Give me a minute here. I'm waiting on a long build, so I'll try to go back and decipher it again and provide a summary of what I do.

[Dean Roddey]

Just for posterity's sake, here's my DrawTextFX method, which is on my graphics device wrapper class. Since this is down at the OS wrapper level, there's some direct calls to Windows APIs here, though most of it is still written in terms of my own framework. I thik it's semi-comprehensible with the comments, but let me know if any of it doesn't make any sense to you:


//
// This method provides the support some some fancy text drawing effects.
// We assume the desired font has been set on this device before we get
// called.
//
tCIDLib::TVoid
TGraphDrawDev::DrawTextFX( const TString& strText
, const TArea& areaDraw
, const tCIDWnd::ETextFXs eEffect
, const TRGBClr& rgbClr1
, const TRGBClr& rgbClr2
, const tCIDLib::EHJustify eHJustify
, const tCIDLib::EVJustify eVJustify
, const tCIDLib::TBoolean bNoTextWrap
, const TPoint& pntOffset
, const tCIDLib::TCard4 c4Passes)
{
// If no text, then nothing to do
if (strText.bIsEmpty())
return;

// Remember if this is a blur type effect
const tCIDLib::TBoolean bBlurType
(
(eEffect == tCIDWnd::ETextFX_GaussianBlur)
|| (eEffect == tCIDWnd::ETextFX_DropShadow)
);

//
// Calculate where the text will be. We get the size of the text,
// either single line or wrapped. Then, if we are using one of the
// blue effects, then we adjust the size upwards to account for
// the blur area.
//
TArea areaText;
if (bNoTextWrap)
areaText = areaString(strText);
else
areaText = areaMLText(strText, areaDraw.c4Width());

//
// We'll create temp bitmaps the size of the text area. But if a blur
// is used, we have to increase the size and we'll draw the text inwards
// from the edge.
//
TArea areaBmp(areaText);
if (bBlurType)
areaBmp.AdjustSize(10, 8);

// If we have to do a reflection, this is how many rows in the reflection
const tCIDLib::TCard4 c4ReflRows = tCIDLib::TCard4
(
areaBmp.szSize().c4Height() * 0.65
);

//
// We have a further complication if a drop shadow or reflection and
// there's an offset. If the offset is in the direction of the
// justification, then we cannot push the drop shadow in that direction.
// It would go out of the area. Instead we have to move the regular text
// in the inverse direction.
//
// If the offset is in the opposite direction of the justification (or
// the justification is centered), then we can just move the regular
// text. So we set up an offset for each of them, either of which might
// be zero in one or both directions.
//
// Note that for the reflection scenarios, negative vertical offsets are
// not an issue, since the reflection is always under the text and can
// only move downwards. And we use the opposite points in that case.
//
// And, in the reflection scenario, if bottom jusified, we'll always
// move the text upwards by the number of reflection lines so that the
// reflection ends up bottom justifed (on top of any offset.)
//
TPoint pntShadowOfs;
TPoint pntShadowTxtOfs;
if (eEffect == tCIDWnd::ETextFX_DropShadow)
{
if (((pntOffset.i4X() < 0) && (eHJustify == tCIDLib::EHJustify_Left))
|| ((pntOffset.i4X() > 0) && (eHJustify == tCIDLib::EHJustify_Right)))
{
// Move the text the other way
pntShadowTxtOfs.i4X(pntOffset.i4X() * -1);
}
else
{
// No special case, so the shadow can move
pntShadowOfs.i4X(pntOffset.i4X());
}

if (((pntOffset.i4Y() < 0) && (eVJustify == tCIDLib::EVJustify_Top))
|| ((pntOffset.i4Y() > 0) && (eVJustify == tCIDLib::EVJustify_Bottom)))
{
pntShadowTxtOfs.i4Y(pntOffset.i4Y() * -1);
}
else
{
// No special case, so the shadow can move
pntShadowOfs.i4Y(pntOffset.i4Y());
}
}
else if ((eEffect == tCIDWnd::ETextFX_Reflected)
|| (eEffect == tCIDWnd::ETextFX_GradientRefl))
{
if (((pntOffset.i4X() < 0) && (eHJustify == tCIDLib::EHJustify_Left))
|| ((pntOffset.i4X() > 0) && (eHJustify == tCIDLib::EHJustify_Right)))
{
//
// Move the 'shadow' the other way, actually the real text in
// this case.
//
pntShadowOfs.i4X(pntOffset.i4X() * -1);
}
else
{
// No special case, so the reflection can move
pntShadowTxtOfs.i4X(pntOffset.i4X());
}

if (eVJustify == tCIDLib::EVJustify_Bottom)
{
//
// Move the 'shadow' the other way, actually the real text
// in this case.
//
pntShadowOfs.i4Y(pntOffset.i4Y() * -1);

pntShadowOfs.AdjustY(tCIDLib::TInt4(c4ReflRows) * -1);
}
else
{
// No special case, so the reflection can move
pntShadowTxtOfs.i4Y(pntOffset.i4Y());
}
}

// We draw the effect text into these bitmaps
const TSize szBmp(areaBmp.szSize());
TBitmap bmpDraw
(
szBmp
, tCIDImage::EPixFmt_TrueAlpha
, tCIDImage::EBitDepth_8
, kCIDLib::True
);

// This is used to create the alpha mask
TBitmap bmpMask
(
szBmp
, tCIDImage::EPixFmt_TrueAlpha
, tCIDImage::EBitDepth_8
, kCIDLib::True
);

//
// The actual graphical text is drawn into the text area, centered
// in the bitmap area. In some cases the are the same size, so this
// will have no effect.
//
TArea areaFXText(areaText);
areaFXText.CenterIn(areaBmp);

[Dean Roddey]

Continued...



// Now let's draw the text into the bitmap to manipulate
{
TGraphMemDev gdevDraw(*this, bmpDraw);
TGraphMemDev gdevMask(*this, bmpMask);

//
// And now let's draw the text into the bitmap. We justify it
// as it would be (left or right-wise anyway, in the final
// drawing.
//
{
//
// Get a copy of the font handle of the our device so
// that we can set the same font on our mask device.
//
LOGFONT LogFont = {0};
::GetObject
(
::GetCurrentObject(hdevThis(), OBJ_FONT)
, sizeof(LOGFONT)
, &LogFont
);
TFontSelAttrs fselToUse(LogFont);
TGUIFont gfontToUse(fselToUse);
TFontJanitor janFont(&gdevMask, &gfontToUse);

gdevMask.eBackMixMode(tCIDWnd::EBackMixMode_Transp arent);
gdevMask.SetTextColor(facCIDWnd().rgbWhite);

// And draw the text into the bitmap
if (bNoTextWrap)
{
gdevMask.DrawText
(
strText
, areaFXText
, eHJustify
, eVJustify
);
}
else
{
gdevMask.DrawMultiText
(
strText
, areaFXText
, eHJustify
, eVJustify
, kCIDLib::True
);
}
}

if ((eEffect == tCIDWnd::ETextFX_Gradient)
|| (eEffect == tCIDWnd::ETextFX_GradientRefl))
{
gdevDraw.GradientFill
(
areaBmp
, rgbClr1
, rgbClr2
, tCIDWnd::EGradientDir_Vertical
);
}
else if (eEffect == tCIDWnd::ETextFX_DropShadow)
{
gdevDraw.Fill(areaBmp, rgbClr2);
}
else
{
gdevDraw.Fill(areaBmp, rgbClr1);
}

TPixelArray& pixaDraw = bmpDraw.pixaData();
TPixelArray& pixaMask = bmpMask.pixaData();

// Tell it to do pre-multiplication as it applies (last parm)
pixaDraw.CreateAlphaChannelFrom
(
pixaMask, TPoint::pntOrigin, kCIDLib::True
);
}

// Blur the bitmap if it's a blur type
if (bBlurType)
{
TPixelArray& pixaMask = bmpMask.pixaData();
TPixelArray& pixaDraw = bmpDraw.pixaData();

tCIDLib::TCard4 c4ActualPasses = c4Passes;
if (!c4ActualPasses)
{
// They want us to provide default
if (eEffect == tCIDWnd::ETextFX_GaussianBlur)
c4ActualPasses = 2;
else
c4ActualPasses = 2;
}
else
{
if (c4ActualPasses > 6)
c4ActualPasses = 6;
}

//
// We use one of the special blur orders that are used for creating
// fast blurs of a reasonable size, either 1 or 2. We try to adjust
// this based on font size, so that we use 1 for fonts under a
// certain size. This keeps the blur more in proportion to the
// font.
//
tCIDLib::TCard4 c4Order = 2;
TEXTMETRIC OurMetrics;
if (::GetTextMetricsW(hdevThis(), &OurMetrics))
{
if (OurMetrics.tmHeight < 20)
c4Order = 1;
}

for (tCIDLib::TCard4 c4Index = 0; c4Index < c4ActualPasses; c4Index++)
pixaDraw.GaussianBlur(c4Order, &pixaMask);
}

//
// Set a clip region so that we don't draw outside the lines.
//
TGUIRegion grgnClip(areaDraw);
TRegionJanitor janClip(this, grgnClip, tCIDWnd::EClipMode_And);

// Blit the image to the target area
TArea areaTar(areaBmp);
areaTar.JustifyIn(areaDraw, eHJustify, eVJustify);
{
TArea areaSrc(areaBmp);
areaSrc.ZeroOrg();

// If there's an offset, then apply that
TArea areaShadTar(areaTar);
areaShadTar.AdjustOrg(pntShadowOfs);

AlphaBlit(bmpDraw, areaSrc, areaShadTar, 0xFF, kCIDLib::True);
}

//
// If they want it reflected, then we need to flip the image in the
// horizontal axis (i.e. make it upside down), and then apply an
// alpha gradient to it to make it go to completely transparent by
// haflway down.
//
if ((eEffect == tCIDWnd::ETextFX_GradientRefl)
|| (eEffect == tCIDWnd::ETextFX_Reflected))
{
if (c4ReflRows > 4)
{
TPixelArray& pixaDraw = bmpDraw.pixaData();
pixaDraw.FlipVertically();
pixaDraw.ScaleAlpha(tCIDLib::EDir_Below, 0, c4ReflRows);

TArea areaReflSrc(areaBmp);
areaReflSrc.c4Height(c4ReflRows);
TArea areaReflTar(areaReflSrc);
areaReflTar.i4X(areaTar.i4X());

if (eVJustify == tCIDLib::EVJustify_Bottom)
{
// Put the reflection at the bottom
areaReflTar.JustifyIn(areaDraw, eHJustify, eVJustify);
}
else
{
// Put it at the bottom of the regular text
areaReflTar.i4Y(areaTar.i4Bottom());
}

areaReflTar.AdjustOrg(pntShadowTxtOfs);

AlphaBlit(bmpDraw, areaReflSrc, areaReflTar, 0xFF, kCIDLib::True);
}
}

//
// If doing a drop shadow, we can now just draw the text normaly over
// the top of the blur.
//
if (eEffect == tCIDWnd::ETextFX_DropShadow)
{
SetTextColor(rgbClr1);
eBackMixMode(tCIDWnd::EBackMixMode_Transparent);

//
// Take the bitmap area and justify it within the drawing area,
// which is how positioned the bitmap itself. Then center the
// text area within that, which is how the text was positioned
// within the bitmap. This should leave us at the same place.
//
areaBmp.JustifyIn(areaDraw, eHJustify, eVJustify);
areaText.CenterIn(areaBmp);

//
// It is inexplicable why this is required. The above adjustments
// of the area should leave this drawn text exactly centered over
// the blurred text, but it doesn't.
//
areaText.AdjustOrg(-2, -3);

// Apply any drop shadow text offset we calculated above
areaText.AdjustOrg(pntShadowTxtOfs);

if (bNoTextWrap)
{
DrawText
(
strText
, areaText
, eHJustify
, eVJustify
);
}
else
{
DrawMultiText
(
strText
, areaText
, eHJustify
, eVJustify
, kCIDLib::True
);
}
}
}

[brianmount]

Thanks; I'll take a look.

Regarding the images, there isn't a DrawBitmapMasked message in the RIVA protocol, correct? I am getting the masked alpha blit messages, but the ones with the odd bitmap modes are DrawBitmap messages, if I recall correctly.

[Dean Roddey]

Thanks; I'll take a look.

Regarding the images, there isn't a DrawBitmapMasked message in the RIVA protocol, correct? I am getting the masked alpha blit messages, but the ones with the odd bitmap modes are DrawBitmap messages, if I recall correctly.

Oh, yeh, that's right. I'm losing my mind. Now I remember the discussion fro the other day. There isn't one, and they are being passed through as regular draw bitmap commands for some silly reason. We need to add a DrawBitmapMasked command. And I'm sure that, if you are getting bogus raster ops values, that's why. Because it also isn't setting that field.

So as soon as we get 3.2 out, I'll jump onto the V2 protocol changes and get that done, and we'll fix this and the other things you guys have been asking for. So, soon now.

[brianmount]

We have a template that contains a PNG file. The original PNG did not define a transparent color, but Rob marked white as transparent in the interface editor. In the editor, the image shows up masked properly, but my program is missing the transparency, and showing a white fill rectangle around the image.

What is the effect of setting a transparent color in the interface editor? What sort of file do you wind up sending? Will it use color transparency, or alpha transparency?

[Dean Roddey]

We have a template that contains a PNG file. The original PNG did not define a transparent color, but Rob marked white as transparent in the interface editor. In the editor, the image shows up masked properly, but my program is missing the transparency, and showing a white fill rectangle around the image.

That is to be expected since the masked blit operation isn't supported in the RIVA protocol right now, so you are just getting it as a regular blit. So you are drawing the non-masked version of it.

What is the effect of setting a transparent color in the interface editor? What sort of file do you wind up sending? Will it use color transparency, or alpha transparency?

Normally you wouldn't do it for a PNG file, since they are alpha transparency based, though you can. What it should do (and will once we do V2 of the protocol) is send you a masked blit command, which will reference the image as usual, but also provide you with a transparency color. You would grab the image from your cache, mask it with the color, and draw the masked version.

The way it normally works is that you create a mask image, which is a monochrome version of the image where every pixel that is not of the color is black and every pixel that is of the color is white. And you create a 'masked off' version of the original. Then you use this with the correct raster op to create a 'hole' in the screen. Then you use another raster op to then blit the masked off image into that hole. This process is pretty documented out there in the internet if you want to look it. If you search for bit blit and color transparency you should find plenty of descriptions. The specific details will depend on the OS API.

I'm thinking that the RIVA clients may want to have the option to store masled versions of images. If you are ever asked to draw an image masked, then you will always be asked to draw it masked, and with the same color. Because the image is put into the repository as a color based transparency image with a particular color.

So, if you ever get a request to do a masked draw of the image, you can probably go ahead and just put the monochrome mask image into the image cache and keep it around, along with the pre-masked original image. Then, when you are asked to draw it masked, you already done all the work and just quickly do the two blits that will blend it into the background. This is what the regular IV does. Each cache entry has the option to hold a mask in addition to the image itself, and a flag that indicates whether it's a masked image or not.

[brianmount]

What is special action 6? It may be called "Clock Blanker" in the interface viewer, since that's what my friend called the button. I only have actions up to 5 defined in my old copy of the cqc.h header file.

[Dean Roddey]

What is special action 6? It may be called "Clock Blanker" in the interface viewer, since that's what my friend called the button. I only have actions up to 5 defined in my old copy of the cqc.h header file.

Yeh, it is the clock blanker, which has gotten ahead of the protocol. I'll get that one into the V2 version.

[SamVimes2]

Dean,

What is the difference between the 3 other blanker options? I created buttons for him to demo each action but they all seem to do the same thing in the real IV (blank the screen until I click).

[Dean Roddey]

Dean,

What is the difference between the 3 other blanker options? I created buttons for him to demo each action but they all seem to do the same thing in the real IV (blank the screen until I click).

One of them just puts up the blanker window. One puts up the window with the clock, and the other puts up the blanker window but also turns off the monitor (blank and blanker.)

[sic0048]

Did something change with 3.2.0 that broke the Riva system? I cannot seem to get it working now. I had it working at one time, but haven't tried in a while. I tried setting up a new RIVA client using a iPaq 4155 as well as a desktop RIVA client.

Here is the error I am getting on the desktop client.

http://i185.photobucket.com/albums/x46/sic0048/RIVAError.png

[potts.mike]

I have gotten a couple errors as well. mostly about not being able to find a template but a few others I don't remember. If I try and logon again it always seems to work. Maybe it is related to the new licensing setup.

[brianmount]

SamVimes and I have returned to the problem we see on one user's template, where the first time a button is pressed it does not visually highlight, even though the button press registers with CQC. On subsequent presses, it highlights properly.

As far as I can tell, there is a problem with the CQC server. The first time the button is pressed, I receive an AlphaBlit message with an alpha of 0. When the button is released, another AlphaBlit message with an alpha of 0 is received. On subsequent presses, a DrawBitmap is received, and again the AlphaBlit with alpha of 0 is used to unhighlight the button when it is released.

It looks like the AlphaBlit used to "highlight" the button when it is first pressed is identical to the AlphaBlits used to unhighlight the button when released. So I can't, for instance, detect an alpha of 0 and set it to 255, If I do that, all the buttons look permanently highlighted.

Maybe I'm missing something, but it really looks like the problem is on the server side. I think SamVimes will be able to send a sample template demonstrating this problem if it helps. Or we can send you connection information so you can connect to the sample template with your favorite debugging RIVA client. Thanks.

[Dean Roddey]

Maybe I'm missing something, but it really looks like the problem is on the server side. I think SamVimes will be able to send a sample template demonstrating this problem if it helps. Or we can send you connection information so you can connect to the sample template with your favorite debugging RIVA client. Thanks.

Yeh, if you can send me something that reproduces it I can look at it. He sent me one before but it worked fine for me so I coudln't get it to do anything wrong. Maybe this time it'll fail for me also.

[SamVimes2]

Here's a trimmed down version of the template with just two buttons.

[brianmount]

Dean,

When using this test template, what specific message do you see the client receiving when the button is first pressed? When it is released? When it is pressed a second time?

[Dean Roddey]

Dean,

When using this test template, what specific message do you see the client receiving when the button is first pressed? When it is released? When it is pressed a second time?

Basically, because of the support of, and pretty ubiquitous use of, transparency, any redrawing effectively just does a recursive redraw of anything that intersects the affected area. So, in the simplest of scenarios, with a button on a single colored background, you'd get something like a push of the graphics state, a fill of the area with the current color, if it's an alpha based image then an alpha blit of the image, then a pop of the graphics state. If it also has text, then there'd be pushes and pops of the font and text color and the text drawing of course, after the draw of the image.

The release would be the same thing basically, since they really are the same operations.

I may be missing some small housekeeping calls wrt to push/pop of state, but basically that would be it.

[brianmount]

That makes sense, but my question here is a more empirical one: What actual image draw message do you see coming out of the CQC server when you press the button on this specific template, when you release it, and so on? I turned on the debug flags in my code and saw the AlphaBlit with alpha of 0, as described earlier.

[SamVimes2]

Hey Dean,

Do you see the same thing as Brian when you debug this template? How is the client supposed to react?

Thanks!

[Dean Roddey]

Hey Dean,

Do you see the same thing as Brian when you debug this template? How is the client supposed to react?

Thanks!

Oops, actually I got distracted and never even tried it. Of course now I fixed the draw bitmap mode thing for non-alpha based bitmaps, which might be the problem, but I'll give it a try and see what it does.

[Dean Roddey]

OK, so running it in the IV and my RIVA client, I see a screen with 1 and 2 buttons that have no background (no unpressed image. When I press them they light up with a blue background. Is that what I'm supposed to be seeing? If I move the mouse in and out of the buttons they unhilight and highlight again as they should.

The Unpressed image is enabled, but no image is set. That means that you are probably goig to get a draw command for a 1 pixel transparent image when the button isn't pressed, since that's what'll be there until an image is set. There's no way for CQC to know that there's no image. If you enable the image, it's legal to have a basically 1 pixel transparent image. It's sometimes done for specific purposes. So, if the image is enabled, it will be drawn, though in this case, the drawing will have no real effect. The drawn code doesn't try to figure out if an image would actually have any visual effect.

[brianmount]

Can you tell what messages you are getting from the server? For some reason I seemed to be receiving an AlphaBlit the first time the button was pressed, and a DrawBitmap on the second and subsequent presses.

[Dean Roddey]

Here is the updated technical document. The V2 stuff is at the end. I'm just doing a separate section for each version, to keep them strictly separated. I'll update first post of this thread with the header changes.

RIVA V2 Doc (http://www.charmedquark.com/WEb2/Downloads/Documents/3_4/RemoteViewerProtocol_3_4.pdf)

[SamVimes2]

Hi Dean,

First, will web image widgets "just work" in the newest beta? I don't see anything about supporting them in the client in the V2 docs.

Also, is it correct that Brian sees an AlphaBlit message the first time a button is pressed, and then DrawBitmap messages on the second and subsequent presses? That inconsistency seems to be the cause of the "blue button" problem.

Thanks!

[Dean Roddey]

Hi Dean,

First, will web image widgets "just work" in the newest beta? I don't see anything about supporting them in the client in the V2 docs.

Oh, sorry. I forgot to update that. Yeh, they should just work. All that really changed is that there is now a new type of image path. I should update the document though to reflect that. You'll just pass the path back in as you always would in order to get the image for display.

You may want to cache them separately from repository images, I dunno. I do, but it may not be necessary. Given that they'll be used in some cases as media cover art, probably it's best to, so that they don't push the important stuff out of the image cache. So I should have discussed that as well. I'll update the document.

Also, is it correct that Brian sees an AlphaBlit message the first time a button is pressed, and then DrawBitmap messages on the second and subsequent presses? That inconsistency seems to be the cause of the "blue button" problem.

Thanks!

Sorry, I keep getting distracted from this by other things. I'm knee deep in Silverlight and Expression Blend. I'll take a look at this after supper.

[Dean Roddey]

I updated the document. Not much more to say than what I just said, but check it and make sure it makes sense to you.

[Dean Roddey]

OK, the deal is is that image is true color, not true color with alpha. So it can't be alpha blitted it has to be drawn as a regular bitmap. I.e. it's a 24 bit per pixel bitmap, not a 32 bit per pixel bit map, so it's basically just a regular old bitmap and you should get a DrawBitmap command for that.

[brianmount]

I'm not sure that answers my question. First of all, I appear to be getting AlphaBlits with an alpha of zero. That's legal, right? If I understand the protocol specification correctly, I should apply that alpha to the entire image, and then draw it. Of course that will have no effect with an alpha of zero, but it's legal, and in fact desired when the button is released, because the highlight should disappear.

But more importantly, I am also getting an AlphaBlit with an alpha of zero the first time the button is pressed. Maybe I should be getting a DrawBitmap as you say, but that's not what I see coming from the server.

Are you able to check what messages the server sends out for the problem template?

[Dean Roddey]

If you have an image enabled but undefined, that's probably what you would get for that image. It'll be a 1x1 transparent image most likely since that's what the bitmap class will default itself to until some content is set on it. So when the button is being drawn unpressed, that's like what you will get.

I did debug into it far enough to see that I am getting a DrawBitmap when the button is pressed, and that's what prompted me to go look at the image and notice that it had no alpha. I checked the path so I know it was for the drawing of the pressed image. When it's released, you'd get the fill of the area and the draw of the default undefined image again.

But I'll get more info on exactly what's happening.

[SamVimes2]

I can confirm the web image widgets are working with no client changes necessary in 3.3.1. Way to go Dean!

Looking forward to seeing that other info...this 'blue button' thing has turned into our unicorn...

[brianmount]

Now that I'm getting the Web image widget images, I need to figure out what to do cache-wise. Does the RIVA server use the same serial number semantics for these images, so that I can safely cache images until the serial number changes?

[Dean Roddey]

Now that I'm getting the Web image widget images, I need to figure out what to do cache-wise. Does the RIVA server use the same serial number semantics for these images, so that I can safely cache images until the serial number changes?

Check the updated RIVA protocol document, which discusses that in the section about image management. See if that makes sense to you, which will be a good sanity check on what I've written. It's linked to in the first post of this thread.

[brianmount]

If it's alright, I'm moving this whole debugging-the-missing-highlight-image thing back to the RIVA thread, because it seems like it belongs here. It might be of interest to other RIVA developers, but won't be of any interest to end users of the iPhone (or any other) client.

Thanks for your debug log, Dean; that's very helpful. First of all, I see that I'm not sending the right protocol version. That's why I didn't see the new template message; you weren't sending it to me, because I was still using protoVer = 1. Am I supposed to set it to 2 now, or some other number?

Also, I see that, when you connect to Rob's server, you are getting AlphaBlits in the initial screen paint (serial numbers 26, 45, 78 and 97). I think these have alpha 0, and so have no effect, which is the right behavior. But you didn't receive those messages when you connected to your own server. So something must be different about Sam Vimes' template configuration, highlight images, or something. Do you know what that could be?

Of course, that still doesn't answer the question of why you are receiving a DrawBitmap as message serial number 144, whereas I get an AlphaBlit in the same position in the message stream coming from the same server. I remain stumped on that. Is it possible I'm sending something different at login time -- some flags detailing my screen resolution or capabilities -- that result in different server behavior? What values does your client send in the LoginRequest message?

[Dean Roddey]

You can set the version to 2 if you want to get the new stuff. 1 is still supported for backwards compatibility, though since any client would likely just ignore anything it didn't understand it's only a formality I guess.

For the alpha blits during initial drawing, maybe there are some other widgets on the version of the template he has or something, compared to the one he sent me? If there was some widget there that is image based but has no image set for one of the enabled images, that can happen. You'll get a 1x1 transparent image, probably with no name. What image name are you getting with those initial alphablit drawing operations?

[brianmount]

I receive "CQCRepo::\User\iPhone\keypresshighlight", serial number 1. Source rectangle 1/3/102/62, target rectangle 109/93/102/62, alpha 0, flags 0. It's the same thing I get later in the DrawBitmap (upon pressing the button a second time). Presumably, you are receiving the same thing from Rob's server.

[Dean Roddey]

And that is the image set up as the pressed image, right? It's not set for any other of the button's image types?

[brianmount]

I'm not sure. Commander Vimes, sir, can you shed light on the image setup of the buttons on the test template?

[Fonceur]

I checked the new template message and it's working fine for me. I get the right info and whatnot. The structures are correctly within the packing pragma so it shouldn't be that the structure is not appropriate byte packed.

[Dean Roddey]

I'll check it out and see. Maybe I whacked something. Hmmm... I wonder if maybe I got it outside of the packing pragma or something (which I'd not have noticed necessarily since both of my sides would still see it the same.)

[Fonceur]

The login challenge can include an error message if the request fails. Only those structures that include text will have those extra bits at the end, but in some cases the string is empty, in which case you have an empty length. So if the c1Error field of the login challenge is set, there's a string at the end with the error message, else it's the empty one.
Just a suggestion for the RIVA 2.0 protocol, but what if you stuck with the original structure (without the Card4 padding) for the normal opCode. Then you could use opCode + X when a single text is included, and opCode + Y when 2 strings of text are included. Along those lines, let say a challenge failed and the Status structure is totally different (since there is no role or session cookies to return), then you could use opCode + Z or such... The values of X, Y, Z pretty much depends on which structures can have text, which seems to require testing to determine it... I guess if you are afraid of running out of opCode, you could either use Card4 for the opCode or add an extra Card1...

The point is that from the opCode and associated structure, we should already know how to read the message, without having to deal with different structures that should have their own opCode to start with....

[SamVimes2]

And that is the image set up as the pressed image, right? It's not set for any other of the button's image types?

Correct.

The unpressed image is enabled but not set. Nothing else is enabled.

Could somehow RIVA be confusing the pressed and unpressed images?

[Dean Roddey]

It may be that, if you remove the image, but it image slot is not disabled (in this case because it can't), that it will send a previously set image name because it's not getting cleaned out or something when the image is removed.

[Dean Roddey]

I checked the new template message and it's working fine for me. I get the right info and whatnot. The structures are correctly within the packing pragma so it shouldn't be that the structure is not appropriate byte packed.

I accidentally edited Fonceur's message above instead of doing a reply. Oops, no way to get it back now. Anyway, I tried it out and it's happy for me. Perhaps Brain can report what he's seeing.

[Fonceur]

I checked the new template message and it's working fine for me.
My bad, it seems I was reading Card2 and didn't know the template's name was appended at the end...

[Fonceur]

Does this seem like a good match for the clip mode?

c1ClipMode_And = 0; --> INTERSECT
c1ClipMode_Copy = 1; --> REPLACE
c1ClipMode_Diff = 2; --> DIFFERENCE
c1ClipMode_Or = 3; --> UNION
c1ClipMode_Xor = 4; --> XOR

I also have access to REVERSE_DIFFERENCE... It's mostly the Copy that has me worried...

[Dean Roddey]

Seems reasonable to me, if the modes actually do what the names would seem to imply.

[Fonceur]

Seems reasonable to me, if the modes actually do what the names would seem to imply.
I was afraid of that too, as it means I have to hunt for the bug(s) somewhere else... ;)

[Fonceur]

c1ClipMode_And = 0; --> INTERSECT

Actually, this one didn't seem to work, I switched to UNION instead and so far it seems OK. Of course none of the test templates are loading a popup or really have any overlapping regions, so the ClipArea usage hasn't really been representative...

[Fonceur]

- There is a new Ping command which simple clients can use if they want a persistent image download connection. There's a chance in certain simple templates that there will be no changes for over a minute, and the image server could time out. So if you've made no snapshot requests in around 45 seconds or so, send a ping to keep the connection alive.
On page 17 of the doc it says 20 seconds, but the .NET RIVA client seems fine with the 45 seconds... ;)

[Dean Roddey]

I'll have to look at it, but it's probably suggesting that you don't go longer than that, because you don't want to let it drop and there can be delays. So it's always best to allow for that.

[Fonceur]

So for an image download, I am supposed to send:

THeader hdrInfo;
TCard1 c1Flags;
TCard1 ac1SessCookie[16];
TCard4 c4SerialNum;
TCard4 c4PathSize;
UTF8 Path;

Or am I missing something?

[Dean Roddey]

Oh, no, you send the TReqImgDownload outward from your side. That's what you get back as the start of the download process.

[Fonceur]

Oh, no, you send the TReqImgDownload outward from your side. That's what you get back as the start of the download process.
I am not following you... Based on the documentation:

- Connect to port 13517.
- Send TReqImgDownload (containing what I mentioned).
- Receive TReqImgStart (containing the image).

But it seems to just times out with my TReqImgDownload...

[Dean Roddey]

Oh, I was looking at the others as actual members of the structure. Sorry. Anyway, are you sending it to the image download port? There are two separate ports involved, one is for normal traffic and the other is for image downloads.

[Fonceur]

Oh, I was looking at the others as actual members of the structure.
Well, it's like the other messages where the "text length" + "utf8 text" is included in the load, but not part of the "official" structure, no (which I've already complained about)?

Anyway, are you sending it to the image download port?
Yes, I was sending the request to 13517, but I guess I need to send it to 13516 and 13517 is for the download only... While that does make sense, it wasn't exactly obvious... ;)

[Fonceur]

Actually sending the request to 13516 doesn't make sense, as you need to include the cookie, which you wouldn't need for 13516 since you are already authorized...

[Dean Roddey]

Yeh, you send it to the other port. Are you sure you are reading back from the other port for the reply?

[Fonceur]

Are you sure you are reading back from the other port for the reply?
Yes, using wireshark, it's not seeing any replies to my query, not even an error message or such... Here's what I am sending:

Header: [Unsigned Byte: 2e, Unsigned Short: 1, Unsigned Short: 40, Unsigned Byte: 82, Unsigned Byte: f1]

Body: [Unsigned Byte: 0, 0 85 231 226 3 115 248 12 17 179 67 157 23 158 0 14, Unsigned Integer: 1, Unsigned Integer: 27, UTF8 String: CQCRepo::\System\LEDs\Glass\Small\Green]

Which wireshark sees correctly as being sent by the app (to port 13517) as:

2e 01 00 40 00 82 f1 00 00 55 e7 e2 03 73 f8 0c
11 b3 43 9d 17 9e 00 0e 01 00 00 00 27 00 00 00
43 51 43 52 65 70 6f 3a 3a 5c 53 79 73 74 65 6d
5c 4c 45 44 73 5c 47 6c 61 73 73 5c 53 6d 61 6c
6c 5c 47 72 65 65 6e

[Dean Roddey]

Doesn't the flag field come before the session cookie? Maybe I'm misreading that, but it looks like you are sending the session cookie then the flag?

[Fonceur]

Doesn't the flag field come before the session cookie? Maybe I'm misreading that, but it looks like you are sending the session cookie then the flag?
The single 0 for the flag is before the cookie (0 85...).

0, 0 85 231 226 3 115 248 12 17 179 67 157 23 158 0 14

I guess I'll have to wait on batwater to come back from vacation to know what the CQC logs have to say about it...;)

[Dean Roddey]

What's this guy for:

Unsigned Integer: 1

There's nothing after the cookie but the string length and the string.

[Fonceur]

What's this guy for:

Unsigned Integer: 1

There's nothing after the cookie but the string length and the string.
Oh, that might be why... From the documentation:

When the client connects to the image server, it will send a TReqImgDownload (...) This will tell the server what image is desired. You will just pass back in the image path and serial number that you received in the drawing command.
That's why I hate things not being spelled out in the structure... ;)

[Fonceur]

OK, that was it, there should not be the serial number of the image in the message.

[Dean Roddey]

Yeh, you get the serial number. So you would only ask if you know that you were asked to draw something that you didn't already have. You get the current serial number back, to store in your cache when you put this new image in it (or replace the existing one in it.)

There's nothing passed that's not in the structure other than the text stuff, so if you see anything in the docs that claims otherwise, let me know. I'll change that one.

[Fonceur]

send a ping to keep the connection alive. It's just an opcode so it uses the TGenOpCode structure.
Is it the same thing as the ACK, to keep receiving more than 200 messages, i.e. header with no load at all. Or is the load supposed to be the unsigned integer for the length of the non existing text, which is not following it? Same thing for the LogOff and other "just an opcode, but not really" messages?

[Dean Roddey]

Yeh, it's just a header. None of those generic message guys take any text.

[Fonceur]

Yeh, it's just a header. None of those generic message guys take any text.
OK, good. Wonder why my ping isn't working then... ;) Do I also need to send a StatusReturn like on the image port?

[Dean Roddey]

It should just require sending out the ping. You are sending it to the regular port right, not the image port?

Be sure to give yourself leeway. Send it around 20 seconds or so, don't wait till it's been 30 seconds, since any delay could put you over the limit.

[Fonceur]

I've shortened it to 20 seconds and indeed that seems to have fixed it, thanks.

[Fonceur]

For images from CQCRepo, everything is fine with the resulting ImgStart.

Now for a Media Browser (MyMovies repository), about one third of the .jpg are being rebuilt, the others are returning null. Looking at the byte array, a working image will end with byte -39. For one image that can't be reconstructed, the last valid byte (1459) was a -76 and the rest was padded with 0 up to byte number 4732... It's unclear if the c4ImgBytes was wrong and I just read some null passed the buffer or if the null were indeed added on the server side...

EDIT: OK, the -76 is not significant, as the other files are cutting at different values, and trimming the file to end with the -76 doesn't make a valid image either.

[Dean Roddey]

JPEG is a chunked format and it can have various chunks in it that aren't image data. So you may be seeing something else besides image data in some cases. And in some cases the images may be just be bad, as often much of the metadata is bad.

[Fonceur]

JPEG is a chunked format and it can have various chunks in it that aren't image data. So you may be seeing something else besides image data in some cases. And in some cases the images may be just be bad, as often much of the metadata is bad.
But the issue is that the .NET client (not a fair comparison since it's just a screenshot) and iRIVA ones are displaying the same template/images just fine...

[Dean Roddey]

How about the standard RIVA client? If it is too, then that would pretty much insure that it would have to be something on your end somehow, though not sure what it might be.

[Fonceur]

How about the standard RIVA client?
I've asked batwater to try that.

If it is too, then that would pretty much insure that it would have to be something on your end somehow, though not sure what it might be.
Maybe the java InputStream is interpreting one of the byte as some End Of File or something odd like that.

[batwater]

Okay, what is the "Standard RIVA client" and where do I find it? I have iRIVA, taRIVA, there's .net RIVA (not using) and the IV.

Thanks
-Ben

[Fonceur]

I am getting the feeling that for bigger images, I end up closing the InputStream as I'm still reading from it, thus the padded null... ;)

[Dean Roddey]

Okay, what is the "Standard RIVA client" and where do I find it? I have iRIVA, taRIVA, there's .net RIVA (not using) and the IV.

Thanks
-Ben

You have to ask to have it installed. It won't be by default. So run a fully custom install and just add it as you are going through.

[batwater]

I have verified that on the RIVA client the test template renders the images from the MyMovies repo as expected.

-Ben

[sic0048]

Dean is talking about the .net riva. You can run it on your Windows computer. It doesn't have to be installed on a mobile device.

[batwater]

Actually there is a Windows RIVA client that can be installed as a part of the CQC installation process.

-Ben

[sic0048]

Actually there is a Windows RIVA client that can be installed as a part of the CQC installation process.

-Ben

Oops, you're right. I know I've installed the Windows version, but that isn't the same as the .net version.

[brianmount]

I'm testing my client against SamVimes' autorotating template, which switches from 320x480 to 480x320 when the iPhone is rotated from portrait to landscape. As I expect, the NewTemplate messages are telling me the proper size, either 320x480 or 480x320. However, after rotation the EndDraw messages tell me that the area to be updated is 480x480.

In version 1 of the protocol, I would use the EndDraw size to determine the scrolling content size. But in version 2, I have the NewTemplate messages to give me that more accurately. So my question is, if I have received a NewTemplate, can I always limit my scrolling content size to the size given by the NewTemplate message, and ignore the EndDraw size? That would work well in the case I describe above, but I want to make sure there aren't situations where no NewTemplate gets sent, in which case I might wind up cutting off legitimate content because I'm using an out-of-date template size.

[Dean Roddey]

The reason for that is that the part that was there was 480 wide and the new part is 480 tall. It doesn't know that you don't have enough to display both of those, and, if you did, you would want to clear the area out to the right, so it's background filled and that's why you get that part included in the full redrawn area.

As a general rule you can always clip any output that you are asked to draw to your actual drawing area if that makes things more efficient, i.e. because some things won't actually get drawn.

[brianmount]

But I do have the ability to display the full 480x480, by scrolling. So up to now, that's what I have done. It starts out 320x480, with no scrolling, but when you turn the device to landscape, the EndDraw tells me 480x480, so I enable scrolling. However, because the template specifically switches to 480x320 when the device is oriented as landscape, the effect of the scrolling is to show you a blank bar of 480x160 below the template. The scrolling is undesirable; it never shows anything useful.

Now that I receive a NewTemplate message telling me that the template is really 480x320, I could use that information to override the rectangle passed to me by EndDraw. Even when EndDraw tells me 480x480, I know the content is really 480x320, because that's what NewTemplate said.

But I'm hesitant to do this, because I wonder why the RIVA server itself isn't using the same logic. It knows internally that the template is 480x320, but it still spits out the full 480x480. Why is that? Should I do the same thing for safety?

[Dean Roddey]

It's because it has no idea what the actual size of the screen is, and it definitely doesn't comprehend things like a screen that can rotate and what orientation it might be in. If it was being displayed in an 800x600 window and it might well be, and it didn't redraw over that part out to the right that was being drawn into and now isn't when the new (tall/skinny) template is loaded, it would leave part of the previous template out there still visible. Since it had to draw into that area to erase it, that area is included in the area redrawn.

[brianmount]

Does the NewTemplate message indicate the size of the maximum rectangle which might ever contain useful content for that template? And is a NewTemplate sent every time the template changes?

[Dean Roddey]

Well, it indicates the size of the base template. Nothing in that template can be drawn outside of it, so effectively that's true. However, a popup can go beyond the bounds of the base template. But, it wouldn't really matter in the case where the base template fits the screen. The extra stuff wouldn't be visible anyway and it would represent a fairly pathological case that I don't think anyone would worry too much about. I think that if you make the assumption that you never actually need to draw anything outside of the area of the base template, then you will be fine. I don't think it's much of a limitation to require folks to keep their popups within the bounds of the parent template if they want paging to work correctly.

[Fonceur]

So how did Sam design his set of templates? Did he create a 320x480 set, then duplicated everything in a 480x320 set, and coded a button to switch between both sets (or maybe he uses a RIVA action...)?

[SamVimes2]

The iRIVA application sends hotkey messages on orientation changes that the user can respond to however. In my case I load the alternate set of templates.

[Fonceur]

OK, that's what I meant with my "RIVA action" guess. ;)

[sic0048]

I'm having troubles with my RIVA clients now. None of them will connect. I use the iPaq, Windows, and Android clients and all were working and now are not.

I get this error in the CQC Log:
An exception occurred in the image download thread
An exception occurred in worker thread X (a number from 1 to 8)
The connection was reset
An exception occurred in the image download thread
etc
etc
etc

I haven't change my setup regarding the RIVA clients or server. I recently upgraded to 3.3.16 but I cannot remember if this is the start of my problems or not.

Any suggestions?

[Fonceur]

I'm having troubles with my RIVA clients now. None of them will connect.
Have you double checked that the RIVA account still tries to use a valid template, and that you hadn't renamed/deleted it?

[sic0048]

Have you double checked that the RIVA account still tries to use a valid template, and that you hadn't renamed/deleted it?

Yup - I've tried multiple users and multiple default templates.

My iPaq RIVA clients seemed to be working fine until I disconnected them and tried to log back in. Now they won't connect either and cycle through getting that error listed in my above post.

It is rather strange, but something is clearly broken. I just don't know if it is on my end or with CQC.

I'd be curious to know if other RIVA users have updated to the latest beta and if their RIVA clients will connect OK.

[Fonceur]

Now they won't connect either and cycle through getting that error listed in my above post.
Have you tried rebooting or at least restarting the CQC service?

[wuench]

I have seen the RIVA server get into a bad state and restarting the CQC Service was the fix. Although this was during the early betas, hasn't happened to me lately.

[sic0048]

Restarting the service fixed the issue. Thanks!

[SamVimes2]

If it's alright, I'm moving this whole debugging-the-missing-highlight-image thing back to the RIVA thread, because it seems like it belongs here. It might be of interest to other RIVA developers, but won't be of any interest to end users of the iPhone (or any other) client.

Thanks for your debug log, Dean; that's very helpful. First of all, I see that I'm not sending the right protocol version. That's why I didn't see the new template message; you weren't sending it to me, because I was still using protoVer = 1. Am I supposed to set it to 2 now, or some other number?

Also, I see that, when you connect to Rob's server, you are getting AlphaBlits in the initial screen paint (serial numbers 26, 45, 78 and 97). I think these have alpha 0, and so have no effect, which is the right behavior. But you didn't receive those messages when you connected to your own server. So something must be different about Sam Vimes' template configuration, highlight images, or something. Do you know what that could be?

Of course, that still doesn't answer the question of why you are receiving a DrawBitmap as message serial number 144, whereas I get an AlphaBlit in the same position in the message stream coming from the same server. I remain stumped on that. Is it possible I'm sending something different at login time -- some flags detailing my screen resolution or capabilities -- that result in different server behavior? What values does your client send in the LoginRequest message?

I am relaunching this discussion. I have confirmed that the problem is also exhibited on the Android RIVA client, so I have to (continue to) assume that the problem is somewhere in the RIVA server or RIVA client documentation.

To recap:
"Assign a 'pressed' image to a button. The first time that button is pressed, it will not display the image."

Dean, can we nail this down once and for all?

[Dean Roddey]

Yeh, we can look at that. It clearly has to be something to do with a confusion between the two ends, since the C++ RIVA client doesn't have this issue. So that, in theory, should provide a big clue, but the big clue isn't coming to me as it should. Let me take care of a couple other things today, and I'll look at it.

Can you verify that you do get a drawing operation for that button's area when it's pressed? I.e. it's not something related to the first click from the RIVA client not getting recognized? If it recognizes the click, you should get a redraw for that area, and of course the activity requested should occur.

If that's the case, it has to be image related somehow, but not sure how. It cant' be something liek the first image download, since lots of images will have been downloaded already.

I can add some more verbose mode logging and then you could put the RIVA server into verbose mode and be able to see what's being logged as you interact with it. I'll work on that tomorrow.

[SamVimes2]

I'm pretty sure it's not an overall first click problem because if you make a template with two buttons with pressed images, they both display the issue, and it recurds:

Load template
Press button1 (no image displayed)
Press button1 (image displayed)
Press button2 (no image displayed)
Press button2 (image displayed)
Press button1 (no image displayed)
etc.

[Dean Roddey]

Are you perhaps not responding to incoming messages while the user has the button pressed? Are you seeing other widgets not show pressed emphasis?

[Fonceur]

Are you perhaps not responding to incoming messages while the user has the button pressed?
I seem to remember that the pressed image was not sent, so it's not about not displaying it... The older messages should have the details of the investigation we did back then...

[Dean Roddey]

It has to send it or the C++ client wouldn't display them, right? So, if it's not sending them, it has to be due to something different between the C++ client and the others. Are you sure that the initial click has the right coordinates?

[Bodshal]

Unless the question is being asked differently, or there's some other state the C client sets that the others don't. :)

[Dean Roddey]

There's not any questions being asked per se. The RIVA server is just spitting out stuff at the RIVA client. So it wouldn't change depending on who its talking to. It's sort of dominating the discussion. The only input from the RIVA client is the click.

And in terms of state stuff in the RIVA client, if it happened just on the first press after the RIVA client connected only, period, then I'd believe it easier that it's some sort of state thing in the RIVA client that doesn't get set until after some interaction occurs. But he was saying it happened on the first press of every button. But there's no state in the RIVA clients that have anything to do with widgets at all.

So really, the only thing that I can see that would be kind of likely is not responding to drawing commands while the mouse/finger is being tracked or something. That would be a reasonable explanation, though it might not be the right one.

Oh wait, looking at what he was saying above, it sounds more like any time you move to a new button, it fails. That almost sounds like an incorrect click position being sent or something, but the release is correct. Otherwise, there's nothing in the RIVA client at all that would know it had moved to a new widget. And certainly there's nothing in the RIVA server that would continue to operate one way while you clicked on one button, then changed when you clicked another. At least nothing I could remotely conceive of, though of course that doesn't mean it couldn't happen.

[Fonceur]

Well, from what I had tested with a Media browser, clicking the same arrow, the first time resulted in no "pressed animation", but the command was executed, while the following had both the animation and execution... I think the initial "pressed animation" was just redrawing the non-pressed state or such.

[potts.mike]

Yeah, for me the command in the button executes on the first try just the pressed image is not drawn.

[Fonceur]

I just tried again with 3.4.4. The first press definitely gets told to redraw the unpressed state, while the second and further get told to draw the pressed state. I will need to make a simpler template and boost the verbose level to see in more details...

[brianmount]

What I saw when debugging was that my client did indeed receive a draw command -- an AlphaBlit with an alpha of 0, which caused nothing to appear on the screen. When the button was pressed a second time, the command came through as a DrawBitmap. But then, when the user switches to another button, again the first draw command is a transparent AlphaBlit, and second and succeeding commands are DrawBitmaps.

So it wouldn't be a positioning error or anything like that. And it's not a caching or buffering thing; I'm getting a command, it's just not one that looks sensible. It's something about the draw command itself.

I think we would want to have the Android client likewise print out some debugging information to see what command is being received when the button is pressed. I look at everything I could think of to see if I was maybe missing some magic bit in the AlphaBlit that would tell me it was really a non-transparent draw, but I couldn't find anything.

And is there a way to have the server log what messages (or at least the opcodes and serial numbers) that it thinks it's sending (obviously only in a special RIVA debug mode)? We could then correlate that with what the client sees without forcing Dean to waste his time helping us debug specific cases.

[Fonceur]

Actually, I am seeing an alpha_blit both time, and the number of messages is exactly the same... Now to print out more values...

Press at: (140, 314)
Sending to the server: PRESS
Writing PRESS
Transmitting Message Header: [Unsigned Byte: 2e, Unsigned Short: b, Unsigned Short: 4, Unsigned Byte: 78, Unsigned Byte: f1]
Transmitting Message Body: [Point: (140, 314)]
Header ID = 128, length = 0, code = START_DRAW
Header ID = 129, length = 11, code = PUSH_CLIP_AREA
Header ID = 130, length = 11, code = FILL_AREA
Header ID = 131, length = 11, code = PUSH_CLIP_AREA
Header ID = 132, length = 0, code = PUSH_CONTEXT
Header ID = 133, length = 11, code = PUSH_CLIP_AREA
Header ID = 134, length = 0, code = PUSH_CONTEXT
Header ID = 135, length = 11, code = FILL_AREA
Header ID = 136, length = 0, code = POP_CONTEXT
Header ID = 137, length = 0, code = POP_CLIP_AREA
Header ID = 138, length = 0, code = POP_CONTEXT
Header ID = 139, length = 0, code = PUSH_CONTEXT
Header ID = 140, length = 11, code = PUSH_CLIP_AREA
Header ID = 141, length = 73, code = ALPHA_BLIT
Image ID = 1, type = CQCRepo, image = \System\General\Icons\Magnifying Glass
Header ID = 142, length = 0, code = POP_CLIP_AREA
Header ID = 143, length = 0, code = POP_CONTEXT
Header ID = 144, length = 0, code = POP_CLIP_AREA
Header ID = 145, length = 0, code = POP_CLIP_AREA
Header ID = 146, length = 8, code = END_DRAW
Drawing on the canvas
Get image: CQCRepo::\System\General\Icons\Magnifying Glass-1
Release at: (140, 314) for a duration of 2596
Sending to the server: RELEASE
Writing RELEASE

[Fonceur]

OK, so without an unpressed image, the first time the alpha blit is in the exact same position, thus no animation, while the second time it is shifted by (1,1).

In the same manner, with different images, the first time it just redraws the initial image, while the second time it loads a different image.

So short of the official RIVA client cheating or using the "screenshot" protocol, I don't understand why they would act differently. ;)

[Fonceur]

And is there a way to have the server log what messages (or at least the opcodes and serial numbers) that it thinks it's sending (obviously only in a special RIVA debug mode)?
Or how would one sniff the packet for the official RIVA client? If I use wireshark, I can see the TCP chatter to taRIVA on another PC, but for the official RIVA client, I'm not seeing any TCP chatter... I assume it's because it's not going through the NIC, so there's nothing to capture...

[SamVimes2]

do you run your server and the official client on the same host? do you use 'localhost' as the address?

alternatively, do you have another PC you could install the RIVA client on?

[Dean Roddey]

So, just as a sanity check, if you have an action in the OnClick, if you press the button and hold it it down for however long, does the action not occur until you release the press while still within the button? And if you move the mouse in and out of the button while holding it down, does the pressed state change then? It should move to unpressed if you move the mouse out of the button and then back in. If not, does it do it the second time you press that button?

Also, are you seeing the same as the iPhone one, where it's actually fine on a given button then you move to another and it does the one time glitch then starts working, then you move back to the original button and it does the one time glitch again?

The C++ RIVA isn't cheating in any way. It's just doing the usual thing and it works. So I know that the RIVA server is at least capable of doing the right thing. It's just a matter of why it's not in this particular case.

[Fonceur]

So, just as a sanity check, if you have an action in the OnClick, if you press the button and hold it it down for however long, does the action not occur until you release the press while still within the button?
No action until the release, same as the official RIVA client (except for the pressed animation).

And if you move the mouse in and out of the button while holding it down, does the pressed state change then?
I see a change on the official RIVA client, but nothing on taRIVA, the CQC RIVA server isn't sending any messages to reload the unpressed image... No messages either on the second time.

Also, are you seeing the same as the iPhone one, where it's actually fine on a given button then you move to another and it does the one time glitch then starts working, then you move back to the original button and it does the one time glitch again?
Indeed, getting the exact same result.

The C++ RIVA isn't cheating in any way.
Well, call me Thomas if you want, but until I can sniff the packets exchanged between the RIVA server and the official RIVA client, I still think it's using the Simple client protocol, which is why it's not seeing what the iPhone and Android RIVA clients are seeing... ;)

[Fonceur]

So if I want to sniff the TCP packets exchanged by the official RIVA client and a RIVA server, I kinda need to connect to a different PC (at least with Wireshark)... How can I change the server to which the RIVA client will connect, I'm not seeing that option anywhere, it only asks for the username and password... Basically, the official RIVA client is auto-connecting to my server, but I want to go connect to batwater's RIVA server...

[Dean Roddey]

Which client are you referring to? I was talking about the C++ one, which is installed by our installer. The target port and address ends up just getting spit out on the command line of the client, so you can modify it there, though it'll go back the next time you run the installer if you don't change it during the install.

The C++ one I wrote so I know it's not doing the simple mode. It has the ability to do the simple mode, via a command line switch, just for testing. But otherwise it does the full protocol.

[Dean Roddey]

So, one obvious thing that's different is that, you move the mouse before you click. Then, on the subsequent click, you probably haven't moved it much. Are you guys doing the appropriate throttling of mouse move messages? Just as another sanity check, move to the button, click it, click it again to make sure it worked, then move the mouse rapidly a bit within the wndow and then come back and click the same button it again. Does it fail again or work?

[SamVimes2]

These are touch-screen devices. No mouse.

[Fonceur]

Which client are you referring to? I was talking about the C++ one, which is installed by our installer.
Yes, that's the one.

The target port and address ends up just getting spit out on the command line of the client, so you can modify it there
So what would be the command line parameters to use at the CQC prompt to start it on the different server? Or do I have to reinstall to select a different one?

It has the ability to do the simple mode, via a command line switch
And you're sure the switch hasn't been stuck in that mode for a while? ;)

[Dean Roddey]

So what would be the command line parameters to use at the CQC prompt to start it on the different server? Or do I have to reinstall to select a different one?

Yeh, just look at what's there in the start menu and start it up that way in the command prompt.

[Fonceur]

This is getting funny... ;) With 2 buttons:

- First click of button one = nothing.
- Second click of button one = press effect.
- First click of button two = nothing.

- First click of button one = nothing.
- Move during that click, releasing outside = nothing.
- Second click of button one = nothing!

- First click of button one = nothing.
- Move during that click, releasing on button 2 = nothing.
- First click of button two = press effect!

[Fonceur]

Yeh, just look at what's there in the start menu and start it up that way in the command prompt.
OK, I wasn't looking at the start menu options, found it now. So connecting to batwater's RIVA server with the C++ RIVA client, I do see the alpha blit of the individual image, which confirms it's the real protocol. By clicking and moving the mouse outside the area, I do see the RIVA server sending the alpha blit to update the image, which it isn't doing for the taRIVA client... And yes I only send the MOVE command every 350ms or so.

I've attached the test template.

[Dean Roddey]

Do you update the position as well when you send the click, to make sure that you are sending the current position when the click occurs? Otherwise, the last position might have been outside of the button last time you updated it.

[Fonceur]

Yes it's sending the current position at that 350ms (or so) mark.

[Dean Roddey]

Yes it's sending the current position at that 350ms (or so) mark.

But you also send the position in the press event. Are you getting the most recent position when you send the press event? If you are just sending the most recent position stored that long ago, it might be outside of the button.