use Perl

• locks versus dirty flags (Score:1)

  by tgape (9307) on 2010.01.01 12:30 (#71462) Journal

  I think you've handled part of the issue very well. For all I know, you've already handled the other part that this post suggests exists. However, some of your post suggests otherwise.

  Here, you're focused on what happens to refresh requests while Padre is in the process of changing data that will inappropriately show if that refresh request is immediately honored.

  What about what happens to a refresh request to something that has not changed? For example, we get a global refresh request, and the file window contents haven't changed - do we re-render the whole window? Or do we see that nothing's changed, so leave it alone/send a cached image?

  I think I've previously worked with editors that did mostly what you've described here which, at the end of an extended update, would occasionally flicker some of the frames a few times, as there were multiple refresh requests during the freeze portion. Can that happen here? If so, is there any simple code that could be used to block it? (It sounds like there could be that code in what you've described, but without diving into the code and studying it for days, I couldn't tell for certain.)

  Reply to This

  • Re: (Score:2)

    by Alias (5735)

    The locking system itself will satisfactorily take care of duplicate refresh requests, because each element that can be refreshed has a method, and each method is just in a boolean state.

    There's some nigglies remaining, but the basics already work.

    Dirty flagging is a possibility, but not something we're doing at the moment.

    We assume that if someone said we needed to refresh, then we really did need to. And with improved locking, we can rely on the caller a bit more to give us more accurate instructions on w