Jump to content

JasonKing

NI
  • Content Count

    46
  • Joined

  • Last visited

    Never

Community Reputation

1

About JasonKing

  • Rank
    More Active
  1. QUOTE(xtaldaz @ May 24 2007, 03:13 PM) Why am I facing your wrath? One second you're telling me it's not okay to bring boxers that can't stay above my ankles, and the next you're threatening to send me down the river in nothing but a life preserver? I'm so confused! Anyway, on-topic, my vote is still for Salt Lick. There's something to be said for being able to roll in your own cooler full of adult beverages. J
  2. QUOTE(xtaldaz @ May 23 2007, 02:12 PM) Swimming in a T-shirt is a lot better than swimming in boxer shorts! While many things in Texas may be big, my ###### isn't. I can't wear my LAVA boxers in public without getting arrested for indecent exposure. I want to be a lot of things in life, but a sex offender isn't one of them. However, my girlfriend loves it when I wear them around the house :laugh: J QUOTE(JasonKing @ May 23 2007, 03:13 PM) While many things in Texas may be big, my ###### isn't. Apparently we're kid-friendly in here and I can't say "arse". D'oh. J
  3. QUOTE(crelf @ May 17 2007, 10:27 AM) We'll see. I won't be working with LabVIEW, so I fear I won't have much to contribute. Mayhaps I'll try to convince them to use LabVIEW for their hardware testing, but I don't know enough about their process at the moment to make a pitch. The work I'll likely be doing will be for the UI on touch screens or a desktop configuration application. LabVIEW probably isn't the tool for either of those. I suppose I can just come here and commiserate with the other ex-NI employees who frequent this joint (Crystal, where you at?) :laugh: Thanks for the good wishes. J
  4. I know I haven't been very active here on LAVA as of late, but I've certainly met some of you either at NI Week or at one of the remote Developer Days. Just wanted to give a heads-up that I am leaving NI at the end of next week and moving to a small startup that makes IP-based distributed audio and video systems. So, if you have any beefs with graphs (esp. the Mixed-Signal graph), charts, events, the code disable node, or the LEGO MINDSTORMS NXT software, please direct them elsewhere For those of you coming to Austin for NI Week, I hope to drop in on the LAVA bbq if it's happening, and the 2nd annual unofficial NI-Week bar crawl, assuming I can find someone to take over the organization of this fine, long-standing tradition. J
  5. QUOTE(Omar Mussa @ May 4 2007, 08:21 PM) However, I do think it's techhnically possible to add this feature (a lot has changed since I was actively involved in development of the graph, so it's possible I'm wrong), so I'd suggest submitting a feature request and detailing how you would use the feature/what problem you're trying to solve. It always helps to have concrete use cases to support the desire for a feature, and helps us make sure we get it right. J
  6. QUOTE(TiT @ Mar 8 2007, 06:58 AM) Sometimes looks can be deceiving. I feel sorry for the ferarri driver who pulls up beside this New Beetle at a stoplight: http://hpamotorsports.com/projects_finished_cannonbeetle.htm http://www.motortrend.com/features/perform...kswagen_beetle/ J
  7. Hi, Omar. Thank you for sharing your thoughts. I can certainly see why those bugs were frustrating to you, and certainly I don't expect you to have to (or even be able to) work around them. It does sound like some of your frustrations are due to not being able to find an (easy) way to get the graph to do what you wanted it to, which is partially a function of wanting to do things with it that we don't intend to be possible. That doesn't mean they aren't valid suggestions of features to add, but I don't necessarily see it as a failing of the control itself (of course I expect you to disagree with this QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM) I think you make a valid point. I am certainly familiar with the need to customize the look and layout of controls in LV front panels. However, I do think it's unrealistic to expect us at NI to forsee all the customization options that you feel are necessary. Remember that our requirements and intended use cases may not include what you would like to use it for. That may be partially due to an oversight on our part, but it might also be by design due to a compromise of function over ease of use or even implementation. Regardless, this gap between the product we deliver and the product you would like can be closed with some simple feedback. We obviously have some feedback now (though not a list of specific properties and methods you'd like to allow the customization you would like - can you provide one?), and can try to incorporate that into the feature in future releases of LabVIEW. An alternative is to get involved in the beta process and have a chance to get the feedback to us sooner (in this case we could have gotten the feedback during the 8.0 beta and hopefully added the properties and methods for that release). QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM) The MSG is an example of a graph whose best features have no API or at best an obscure one that is not well conveyed - so most users will go to great lengths to integrate a different graph (like the XY graph) with a richer API so that they can get the desired user experience. Again, any specifics you can provide will be greatly appreciated. I assure you we do what we can to take all of our users into consideration when designing new features and choosing what properties and methods to expose to allow users to get the most possible out of their use. As one who "owned" the code behind the graphs for many years, I'm very aware that we have users that rely on the ability to customize the look and layout programmatically, as well as demand high performance at the same time. It is frustrating to hear feedback that the "1.0" version of this control was not sufficient to meet your needs, but I do hope that some users are able to get some benefit out of it, and hope that we can address your needs in the future. J EDIT: Omar, I re-read your initial post and see that you filed a few CARs and some product suggestions as well. Thank you for doing that. If you don't mind duplicating your time, listing the desired features (props & methods, primarily) plus use cases, that'd be helpful. Thanks.
  8. Hi, Ton. I can't say I fully understand your complaints. What makes it feel like an "express picture control"? What do you mean by "I need the properties and methods alike the developer experiences the control"? I'm not challenging those statements, I just don't understand them so I'm not sure how to respond, or how we can make the documentation better to address these issues. In short, the mixed-signal graph is intended to allow you to put both digital and analog data on the same graph, sharing an X-scale. I've seen many VIs where users have two separate graphs and have to write a bunch of diagram code to keep the X scales in sync because the data shares the same time axis. This graph should be make life easier for this type of user. Additionally, it does function a bit like an "express" graph because it accepts XY, Waveform, or digital data. This wasn't really the intention when we started out, but it was a nice result of all the other work that had to be done. It's not really meant to be an improved waveform or XY graph, other than it allows one to overlay other types of data with it, and you can use one cursor (a multi-plot cursor) to track values across multiple plots. Anyway, I'm sure you can see what the graph is *meant* to do, but perhaps it fails in that regard. I'd certainly like to understand how it fails, and what we can do to fix that. If it's as simple as beefing up the documentation, that's good news Thanks. J
  9. Hi, Omar. I'm the developer responsible for most of the MSG code. I apologize for the problems you've run into, but they don't sound *that* bad to me. That's not to say they're not a nuisance - certainly they are. But without knowing what you're trying to do with the graph, it doesn't sound like it's unusable. I'd be very curious to see/hear what you are using it for. I've often wondered why I didn't hear much about people using the MSG. Is it too buggy? Do people just not know about it? Etc. Unfortunately I am no longer working on it (and thus don't get the bug reports), but I'd certainly love to hear any feedback and will do what I can to steer things into a more useable direction, as I put a lot of effort into that beast. Regarding adding and removing plot areas via VI Server. For technical reasons, we can't do that while the VI is running, but as a "Scripting" feature such a thing would be possible. Going forward, hopefully those technical reasons can be removed. J
  10. Yes, you are correct. Overall, likely less work is done to draw the transparent graph on top of a picture control rather than the graph+picture control if you are regularly updating the data in the graph (and not the picture control). If both are being updated, then approximately the same amount of work is being done. No, what I'm saying has nothing to do with control vs indicator. Given a control or indicator that has another object on top of it, whenever that control/indicator gets a new value there is a penalty to being redrawn, as we must not only redraw the control/indicator with the updated value, but the object on top of it as well. If instead the control/indicator is on top of another object, when the control/indicator gets an updated value we must only re-draw it, as re-drawing it does not affect the object below it. Transparency really isn't a factor in this issue. J
  11. Your memory serves you correctly regarding which implementation is which (I've attached a screenshot of the diagram to this post). As far as your conclusion...I suppose it depends on what you mean by "efficient". I would summarize it this way: using the transparent graph on top of a picture control does not require a redraw of the picture control every time the graph is updated. However, when using the bgimage of the graph, every time the graph gets redrawn (with new data, etc), the picture must be re-rendered from the picture string (we don't even cache the picture image like we do in a picture control - I'm not sure why we chose to implement it this way as it's inefficient). There's still some quirkiness in the timings I can't figure out if synchronous display is not turned on for the graphs, but it shouldn't invalidate the statement above. The main benefit to the built-in picture properties of the graph really shouldn't be looked at from a performance perspective, but rather that it makes it easier for one to align the picture with the actual data points of the graph. Does that all make sense? J And another note, regarding overlaying controls. It's one thing if the graph is transparent and placed over a control. It's a whole different issue if a control is placed on top of the graph. Any object that has another object on top of it is forced to redraw inefficiently, as we must ensure that we draw back to front. J
  12. It turns out I was wrong in a couple of my assertions above. To clarify: 1) In any timings, the cost to draw the picture control in the first implementation will not be timed. Because the picture control is overlapped by the graph, we will not draw immediately and instead will invalidate our bounds to make sure we re-draw with the new value in the correct z-plane order. 2) Writing any of the plotimages properties of the graph will not cause an immediate draw of the picture data/graph (instead we just invalidate and come back and redraw later). As such, the cost of this call is simply the VI Server overhead and the time to copy over the new picture string. Thus, in neither implementation is the cost of drawing the picture taken into account, except as described in #3. 3) When we draw the graph in the second implementation, we are also forced to re-draw the picture data as well. Thus, the time to update the data of the picture control will include both drawing the plots as well as the picture data. This explains why implementation #1 appears faster than implementation #2. The drawing of the picture data is not measured in #1 (there really is no way other than to pull the graph off of the picture control to ensure we draw immediately). This explains why #1 appears to be faster than #2. J
  13. Gary: Your timings aren't really making a fair comparison. There are a few things to note. 1) The time to write a value to a terminal does not include the time to actually draw the updated value, unless you have Synchronous Display turned on. Try your timings with sync display on and off for the graphs, and see how the timings change. 2) Writing a value to a control's terminal is considerably different from writing the value property. Not only is there the overhead of the VI server call (which in most cases requires a switch to the UI thread), but the call does not return until the control/indicator draws with the new value. Thus, the two calls are not equivilent if you are trying to time them and compare the efficiency. Therefore, in the first case you are not including the time to actually draw the picture control, while in the second you are. 3) In both of your loops, there is a race condition between when the picture gets updated and when the data does. While in the first case, the graph will get invalidated every time the picture gets a new value, in the second case, the graph almost certainly redraws itself every time the background image gets updated. This means that, in both cases, we may draw the data twice for a given iteration if the value is written and then the picture gets updated. I believe over the course of many iterations this should average out, this is another inconsistency that can remove a bit of confidence in comparison of the timings. In summary, I don't think your timings are accurate. Now, it may still be the case that the first implementation is faster, but I highly doubt it's by the factor that you see. Okay, I got over my laziness. If you turn on synchronous display for both the graphs and the picture control, you'll see that #1 is about twice as fast as #2. I don't think this should be the case - chances are we're just being stupid somewhere in the drawing code - but it's certainly a more fair comparison than what you initially discussed. If you change the first implemtation to use a property node for value rather than the terminal (to remove the discrepancy in VI server overhead), you'll see that it takes about 1/3 as long. I cannot explain why this speeds things up, but it's still not as bad as the original numbers you quote. It does look like the picture control is a bit smaller than the graph, so you're drawing a little bit less, but I can't see that explaining the difference. Again, I'm not sure why the built-in option is slower, but at least it's not as bad as you thought J
  14. Do you not think the conditional compile (ifdef) node does? Being able to inline your debugging or profiling code and not having to worry about it getting compiled in a release build, and not having to modify any source code to turn it off or on? I don't know if you were at NI Week and saw any of the sessions on the LEGO Mindstorms software, but for that product we created a native HTML control using the Mozilla gecko rendering engine. It's not in LabVIEW proper yet (still has quite a bit of work to get there), but my hope is that we can not only render remote and local HTML pages, but also use the engine for rich formatting of text using HTML tags. We're continually working to improve LabVIEW for many different types of users - enhancing performance of existing features, making things easier to use for new users, as well as adding features for the advanced users like many of you here. I think to say that the new features in 8.0+ are not useful is a bit harsh, however I can totally understand feeling that they are not useful to you. You've had this ability for a while. Custom probes allow you to create custom behavior like this quite easily. J
  15. Nope, there's not. I agree it would be nice if you could do something like use an unbundler, but the event registration refnum represents something fundamentally different from the user-defined events. J
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.