Bug: Layer names compressing

CleverTagline Posts: 3,337 Ambassador

I've encountered a couple situations where the name of a layer in my comp will somehow "compress," with the displayed label scaling down so that I can't even see the name.  Here's a screenshot of the most recent attack of the compression monster:

It's only happened a couple times, and both times I was looking elsewhere when the change occurred, so I couldn't pinpoint a specific set of steps that led to the problem.  The first time it occurred, I tried numerous things to fix it, but the problem stayed put.  The most recent time (earlier this morning) I collapsed all layers and their contents, and that somehow fixed it.

This is happening in the latest release of HitFilm Express 2017 on my Mac.  System specs:

Mac Mini (Late 2014)
Mac OS X 10.10.5
2.6 GHz Intel Core i5
8 GB 1600 MHz DDR3
Intel Iris 1536 MB


  • JMcAllister
    JMcAllister Posts: 593 Enthusiast

     Happens to me as well, on HitFilm Pro 2017, on Windows 7. I have also seen this in previous versions of HitFilm Pro.

    So this is not specific to Express, not specific to HifFilm 2017, and not specific to either Windows or  OSX (since it occurs in both)

  • Triem23
    Triem23 Posts: 20,679 Ambassador

    Jsbarrett @JMcAllister I've had it happen to me in both Express and Pro 2017, although I can't remember seeing this happen in HF4 or earlier. T'was the first bug I logged in Beta testing.

    Whatever it is, it's something trickier than any of us would think, or it would have been squashed by now!

  • JavertValbarr
    JavertValbarr Staff Posts: 367 Staff

    I just duplicate the layer and delete the compressed one.

  • JMcAllister
    JMcAllister Posts: 593 Enthusiast

    I've definitely seen it in HF4P, can't remember if I ever saw it in HF3P... similarly I don't remember if I saw it in HF2U. TBH I've kinda just accepted this as one of the quirks of the software, so it doesn't really bother me anymore

  • CleverTagline
    CleverTagline Posts: 3,337 Ambassador

    I've only used Express from 2 to the present, and the first time I've encountered it is in 2017. Maybe it's coming in from some of the pro features that were migrated to Express over time?  Long shot, I know.

  • Palacono
    Palacono Posts: 3,425 Enthusiast

    The way text is displayed has changed in 2017. You now get '...' in the middle of words instead of them being truncated by the next field or a panel edge, and it tries to keep the values visible instead of them being hidden by a panel edge as well. 

    Not always entirely successful, as the text starts to be compressed a long time before the values get anywhere near it, but I think this latest update might be slightly better than before. Previously you could compress the text by dragging the margin over to the left, and if you expanded it very slowly: the text would remain compressed. Can't make it do that now.

  • NormanPCN
    NormanPCN Posts: 4,192 Enthusiast

    "The way text is displayed has changed in 2017"

    For the worse IMO. My gripes mostly with the controls panel and the pain when using the particle simulator which has many levels of hierarchy. There is workable workaround. Close and re-open. Results are still not as good as HF4. They don't make them like they use to...

    Over a month ago I installed HF4 to do a comparo video to put in the wishlist. I guess I should post it.

  • Palacono
    Palacono Posts: 3,425 Enthusiast
    edited June 2017

    @NormaPCN ; I'm with you there. "Anc...nt" isn't as useful as "AnchorP". If words were shortened individually instead of as a group you'd get "Anc...Po..." which is slightly more readable, even down to "A...P...", whereas "A...t" is just nonsense. Yes, it's more dots, so why not use 2 instead of 3?

    The only time I think it's better with the current method is when Rotation (Z) would have got truncated  to "Rota" and now says "Rot...(Z)" and then "R...(Z)" but that's about the only one (and X and Y, obvs).

    I think it could be improved by specifying individual words to be shortened where it makes more sense to treat them separately and also only do it from the end, not the middle. Give people the start of a word and they can work out what it was. Give them an end and it's just "Eh?" 

    In some cases the shortening seems unnecessary and a slight twitch on the margin will change words to something one pixel narrower, but 10x less readable. "Op...ty" is not better than "Opacit" IMO.

    I also don't like the removal of the separator bar between names and values. Things could have been improved by allowing you to adjust that line, but now it's gone entirely: the gap between them is too generous, even though it has (might?) have improved in the latest update.

  • NormanPCN
    NormanPCN Posts: 4,192 Enthusiast
    edited June 2017

    @Palacono Yes, the trunc algorithm does suck. In general label truncation is bad, IMO. A slider control works no matter how narrow or wide it is. Precision may be lost in a very narrow slider with  a large range but it still works. Words truncated into nothingness flat out do not work, IMO. Words truncated fall apart in usefulness very quickly.

    2017 seems to bias strongly towards truncating the labels and giving more room to the controls. Bad bias IMO. I don't need a control with 5 inch long slider and a truncated label (yes I have measured). It is a waste of precious screen real estate. The slider would work fine at an inch or two. Also we normally have a text entry control upon which we can mouse drag with greater precision. Again, that always works, but we get truncated labels which don't work, well or at all.

    It seems 2017 wanted to allow panels to go smaller than in HF4. Okay, fine but the result is a step backwards WRT labels IMO.

    Interesting you used a rotate control as an example. The rotation controls can have double line labels basically for free since the little circle adjuster rotation controls have take up more than typical vertical space. So when we get label truncation on rotation controls it is double silly.

    I also don't get the velocity sensitive nature of the label/control proportions. A panel that is 150 pixels wide should be proportioned the same no matter how fast you move the mouse to that final position. The velocity sensitive nature just makes it very inconsistent for users to get the panel sized such that the controls are fully visible. Seriously critical in 2017 given the label truncation bias. If the UI is not consistent and reliable it just makes it harder for users to get a desired result.

    Of all the panel controls proportions algorithms we have in 2017 the one that is used after opening works the best. You definitely get different proportions than a slow or fast drag resize.

This discussion has been closed.