[prev in list] [next in list] [prev in thread] [next in thread]
List: flightgear-devel
Subject: Re: [Flightgear-devel] Property Value Changes in Websocket - Flightgear Ticket 2824.
From: James Turner <james () flightgear ! org>
Date: 2023-11-23 9:24:15
Message-ID: 13D6E338-AAD6-4B3F-9D42-E9751A22265C () flightgear ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On 20 Nov 2023, at 19:41, Patrick Callahan <pat.callahan1@gmail.com> wrote:
>
>
> Using this to drive external hardware, which usually has no more than 12 to 16 bits \
> of precision, will reduce undesired noise. I tried this with \
> PropertyChangeWebsocket, and it dramatically reduced the number of packets sent. \
> There were still missing changes, and I'm still looking for the cause. Clock \
> Seconds however came in like "clockwork".
Yes I would expect this really reduce traffic over the protocols, the floating point \
'noise' causes a lot of spurious changes.
> I agree with making this settable and configurable dynamically as a first step. \
> I'd go with Torsten's zero delta as the default everywhere until it's shown not to \
> do any harm.
Absolutely, a default of zero is the right way to go.
>
> Canvas updating might be an excellent area to explore. You would not want to feed \
> changes to Canvas that do not result in visible changes to the rendering engine. \
> This is similar to not providing cockpit hardware changes that won't move anything \
> on a physical instrument.
Yes canvas is a classic example because many changes will be less than a pixel (often \
much less, but changes in the 0.5 of a pixel do cause rendering changes due to \
rounding)
>
> Do you agree we're on the right track with this idea?
>
I think so, but let's try and find some incremental steps for this, since as you \
pointed out, numerical changes are a very complex area and we probably don't get a \
definitive answer on the behaviour of any particular computation.
Kind regards,
James
[Attachment #5 (unknown)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: \
space; line-break: after-white-space;"><br \
id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 20 Nov \
2023, at 19:41, Patrick Callahan <pat.callahan1@gmail.com> wrote:</div><br \
class="Apple-interchange-newline"><div><meta charset="UTF-8"><div style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br \
class="Apple-interchange-newline">Using this to drive external hardware, which \
usually has no more than 12 to 16 bits of precision, will reduce undesired \
noise. I tried this with PropertyChangeWebsocket, and it dramatically reduced the \
number of packets sent. There were still missing changes, and I'm still looking for \
the cause. Clock Seconds however came in like \
"clockwork".</div></div></blockquote><div><br></div><div>Yes I would expect this \
really reduce traffic over the protocols, the floating point 'noise' causes a lot of \
spurious changes.</div><br><blockquote type="cite"><div><div style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;">I agree with making this \
settable and configurable dynamically as a first step. I'd go with Torsten's \
zero delta as the default everywhere until it's shown not to do any \
harm.</div></div></blockquote><div><br></div><div>Absolutely, a default of zero is \
the right way to go.</div><br><blockquote type="cite"><div><div style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;"> </div><div \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: \
none;">Canvas updating might be an excellent area to explore. You would not \
want to feed changes to Canvas that do not result in visible changes to the rendering \
engine. This is similar to not providing cockpit hardware changes that won't \
move anything on a physical \
instrument.<br></div></div></blockquote><div><br></div><div>Yes canvas is a classic \
example because many changes will be less than a pixel (often much less, but \
changes in the 0.5 of a pixel do cause rendering changes due to \
rounding)</div><br><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, \
0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: \
normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: \
0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;"><br></div><div \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Do \
you agree we're on the right track with this idea?</div><br \
class="Apple-interchange-newline"></div></blockquote></div><br><div>I think so, but \
let's try and find some incremental steps for this, since as you pointed out, \
numerical changes are a very complex area and we probably don't get a definitive \
answer on the behaviour of any particular computation.</div><div><br></div><div>Kind \
regards,</div><div>James</div><div><br></div></body></html>
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic