I’m doing preliminary system design for the following project, likely not to ship to users for 2-3 years, so I’m trying to aim the shotgun ahead of the clay pidgin a bit here on the graphics standards to be followed. Here is a list of project facets:
[ul]
[li] Financial Trading human computer interface HCI mobile application - (users trade all instrument types: stocks, fixed income, options, futures, fx with simple market/limit orders up to full algo orders)
[/li][li] I have to follow a HCI standard expressed in XML that instructs where to draw designated (standard) components/widgets on the screen (high level, not language specific: check boxes, drop downs, radio buttons, text fields, etc.) There are 1000s of “order screen layouts” defined in those xml files. rendering is very loose and adaptable to many environments.
[/li][li] Mobile market primarily with some possible desktop
[/li][li] Rich 3D infographics to be displayed, audio/video to output
[/li][li] Internet transport to server (see notes)
[/li][li] Must have snappy “game like” HCI performance. The snappier the better.
[/li][li] Output from this client application is basically a simple string (a buy or sell message)
[/li][li] Used for simple orders up to very complex orders (Simple: buy/sell at a limit price or the market. Complex: user must enter many order parameters, including multiple pages of parameters, for a complex algo order.
[/li][/ul]
Note 1. Internet performance is of course highly unpredictable
This is not (at least in the first instance) a high frequency trading (HFT) application (e.g. the London Stock Exchange plans to implement trades with an average latency of 126 microseconds! wow man!)
In this application you always have:
[ol]
[li]delay associated with a human entering the order, cuing it up, reviewing, pressing the “send order” button etc., and
[/li][li]the travel time (distance, hops, congestion, latency, etc.), from where the user is signed in at an ISP, to where the exchange (or perhaps a co-located algo engine) exists. Due to the uncertainty of the Internet connection, this can be up to SECONDS (not milliseconds, not microseconds)
[/li][/ol]
Note 2. Good enough timing
Although this client application must endure Internet delay and uncertainty, the server on the other end (which receives trading messages) MAY be involved in HFT. For example, in an algo order the HUMAN can “set it in motion” by entering an order in THIS application and sending it to the server. Once that message arrives at the server its likely that HFT techniques will be used to actually EXECUTE the order, especially if its an algo order e.g - send out 500 separate buy or sell orders on the following list of stocks …, with the following quantities and limit prices …, execute as many as possible for .5 seconds after receipt of this message, after that ASAP cancel all the open limit orders. ) (Its somewhat similar to the President keying in the nuclear codes - not much typing on the president’s side results in a whole lot of action set into automatic execute motion on the upstream “server” end.)
Note 3. Rich 3D graphics
Display needs: while this is not as demanding as gaming per se the display needs run from simple charts, graphs, maps to much more complex, animated “infographics”, video and audio. This is a client application (cell phones, tablets, desktops) - and you can assume the server side has massively “abundant” computational capabilities vs. this client. However, there is some advantage to shipping data to drive the “infographics” on the client if they can rotate the spacial information locally, drill down to what interests them, etc, all without having to endure Internet transport delay.
Note 4. Do the best you can with questionable (and highly variable) Internet connections
The HCI in the application can only be rendered as “rich” as the user’s current Internet connection quality (since the data must be “fresh”). The user (and application) should be able to adjust how much bandwidth is consumed providing rich information (downloading) and delay in rendering due to local issues like CPU, MPU, resolutions, etc. (make choices like download data for local manipulation provided bandwidth is higher than x, or alternatively, conclude that bandwidth is too constricted so process only single “frames” of results at the server side, and send only static images.)
The design should be ideal for cell phones and tablets expected to ship 2 years out; down to current cell phones/tablets currently shipping TODAY with software reasonably updated to the 2 year forward time-frame.
Questions
[ol]
[li]What might be the overall best software architecture here (at the block level) : things like browser / HTML5 (for widgets/controls and form)? Vulkan for the infographic display?
[/li][li]Code for Ios, Android separately for adequate performance?
[/li][li]Go outside the HTML5 browser form for the 3D graphic display and local data navigation? Or just skip HTML5 altogether?
[/li][li]Are there any lightweight (single user client) databases that would be relevant/ideal to cache the infographic data (including spacial) locally to avoid “thrashing” between the client and server as the user twists and slices the data?
[/li][li]What might be the best developer tools, IDEs, APIs to work in?
[/li][li]Are there any 3D “infographic” developer tools that might be relevant (rich charting, graphing, mapping) - ones that might use 3D gaming graphics horsepower to display a very “information rich” display (for example - overlay “smoke” based on statistical confidence intervals, etc). Any IDEs that allow the client to rotate the data field, slice data, show in 3D the slice, etc. Any standards, APIs, etc. between the image displayed and the HCI used to manipulate the image (e.g. forward/back, up/down, left/right, pitch, yaw, roll). Are there HCI “standards” that have worked well in the gaming industry to move players about, tilt/pan/zoom in and out, etc.?
[/li][/ol]
Can you tell I have zero 3D gaming programming experience? Pardon the ignorance, starting to look at advanced graphics at ground zero here. (Remember MDA, CGA and EGA via dip switches…O.K., you get the picture.)
All ideas, tips, pointers, random thoughts, and “got-ya’s” welcome.
Thanks!
Rick