Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
SC has stated that this would compromise performance, so my question is to what degree? Maybe this use to be the case, but I am having a hard time believing that this would present any significant issue to a modern processor. Is there anyone qualified who can quantify the performance differential? Thank you.
Right now you can keep track of the number of trades at the Last until the Last changes, then it resets.
How about the ability to do the same, but for both bid/ask/last? This to me seems like it would allow the counter to reset less often and give an example of the absorption or pressure at the current bid/ask more clearly.
And how about dragging multiple overlaid orders (stops, targets) on the DOM all at the same time? If we have three overlaid orders we have to drag and drop one by one... Not good in fast markets...
Unless it is already possible, but I couldn't find out how to do it...
I have not tried this, but you could write your own custom study which simply calls another study that plots the open. SC restricts built-in studies except PreviousClose and VbP, but they do not restrict custom user studies in the DOM (at least you can browse the list anyway, I have not actually added any).
I don't believe that for a minute. It's 2012, not 1990. Even the most basic budget PC has enough horse power to calculate the anti-aliasing on a line. It's ridiculous, I'm sure there's some other reason such as it would be a lot of effort to redo their studies. They could start with the most common ones such as MAs, and drawing tools and move onto the others later.
I'm puzzled though because the drawing engine should be separate from the studies and they should only have to make changes in their drawing engine. I do have basic programming skills and no experience of implementing a drawing solution. I have however used third-party drawing modules for my own programs, mostly in C#.NET.
Clearly you have no idea what you are talking about, but lets see if we can get enlighten you a bit. You are spot on that todays processors have horsepower to burn, but you have to be able to use it. It can be rather difficult to use all of those cores/threads, especially when the drawing for a program all happens on the main thread. There are newer code architectures that deal with this, but Sierra is clearly written in the old school MFC windows model. I do not expect Sierra to move to the new model, as they have said they are doing everything they can to get rid of .Net, which you need to embrace to move to the new model.
You are also right that the drawing engine is separate, in fact the drawing engine is provided by the underlying runtime (again part of MFC). That old API does not support anti-aliasing, so you would have to do it yourself. You would have to implement something like the Wu Anti-alias algo. You have to do this for every single line/curve that you plot. And what makes it worse, is you basically have to plot into memory, and when you are all done, then bit blast it out to the screen. The other caveat here is that you likely do not get to make use of any video hardware acceleration.
Now will the above break the bank? Perhaps not, but personally, I would rather see my DOM updating in real time on fast days than having a pretty edge on my lines. There are also a lot of other things I would like to see in the platform before they spent time re-doing the entire back end for smooth lines, but long term they do need to get away from the current arch.
I was thinking along these same lines. If my DOM updates are less than the expected 40ms for any reason, then whatever is being beautified needs to be cut, period. Said another way, if Sierra promises a 40ms update interval and something they fundamentally do that can't be changed by the user prevents that, then I am not for it. Only if things are as fast as they would be otherwise, am I okay with this kind of modification.
I would like to see the study have the ability to paint before and after the chart is painting (the before-paint should be after any background clearing/filling is done).
