Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support truecolor #756

Closed
wants to merge 23 commits into from
Closed

Support truecolor #756

wants to merge 23 commits into from

Conversation

Tyriar
Copy link
Member

@Tyriar Tyriar commented Jul 4, 2017

Fixes #484

@Tyriar Tyriar added the work-in-progress Do not merge label Jul 4, 2017
@Tyriar Tyriar self-assigned this Jul 4, 2017
@mofux
Copy link
Contributor

mofux commented Jul 4, 2017

@Tyriar Not sure about typescript (have tried, but didn't get it to work), but with standard javascript es6 you can extend the Array prototype and setup getters like this:

class CharData extends Array {

  constructor(char, width, flags, fg, bg) {
    super(char, width, flags, fg, bg)
  }

  get char() {
    return this[0]
  }

  get width() {
    return this[1]
  }

  get flags() {
    return this[2]
  }

  get fg() {
    return this[3]
  }

  get bg() {
    return this[4]
  }

}

let char = new CharData('a', 1, 0, 1 << 24, 1 << 24);

// will log 'a 1'
console.log(char.char, char.width);

You can actually copy & paste the code snippet into your chrome console and execute it, should work. Not sure about the performance of this though.

@Tyriar Tyriar mentioned this pull request Jul 4, 2017
4 tasks
@Tyriar
Copy link
Member Author

Tyriar commented Jul 4, 2017

@mofux I think the new CharData part is the thing that will cause the issue. What I'm thinking now is either keeping it as is, with my beefy explanation comment and either using constants for the indexes or helper functions to pull the data like this:

export const CHAR_DATA_FLAGS_INDEX = 3;
export function getFlags(charData: CharData) {
  return charData[3];
}

@mofux
Copy link
Contributor

mofux commented Jul 4, 2017

With issue, do you mean that the object instantiation will be slow, or that typescript is not able to extend the Array prototype correctly?

I could write a jsperf test to see if it actually differs if we create an Array through the CharData constructor and access the properties through getters, vs [] direct index access.

Imo using the getters would be the most elegant solution.

@Tyriar
Copy link
Member Author

Tyriar commented Jul 4, 2017

@mofux I mean slow instantiation. I did a small jsperf that tests {} vs [] with a few values/properties each and the array was 20x faster. Checking extends Array would be useful though 👍

@mofux
Copy link
Contributor

mofux commented Jul 4, 2017

I have created a test with jsbench. Looks like using a native array is the way to go 😔
http://jsbench.github.io/#9f772c6df61ca6dea50e39298785d99b

@Tyriar
Copy link
Member Author

Tyriar commented Jul 4, 2017

@mofux results are quite dramatic on my PC 😛

image

@mofux
Copy link
Contributor

mofux commented Jul 4, 2017

Yep 😅. Test number 5 uses a function that gets the array in and returns an object with the mapped values (like a view).

let toCharData = (arr) => ({ char: arr[0], width: arr[1], flags: arr[2], fg: arr[3], bg: arr[4] });

It performs surprisingly well when compared to the direct array read method. But I'm afraid it will increase memory usage, although that might be negligible if the generated object can get garbage collected quickly (because it should not get referenced directly somewhere)

@jerch
Copy link
Member

jerch commented Jul 5, 2017

Eww, I think V8 does some nasty optimization here and you are not measuring the "create an array with data xy" thing. Microbenchmarks are not that useful anymore in a complex environment with a JIT compiler and such.

@coveralls
Copy link

coveralls commented Jul 16, 2017

Coverage Status

Coverage decreased (-0.4%) to 69.778% when pulling 6d4bcbe on Tyriar:484_truecolor_2 into 48dab49 on sourcelair:master.

@coveralls
Copy link

coveralls commented Jul 22, 2017

Coverage Status

Coverage decreased (-0.4%) to 70.008% when pulling fbbd664 on Tyriar:484_truecolor_2 into 2e9177a on sourcelair:master.

Copy link
Contributor

@parisk parisk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linting fix and it's good to go!

@Tyriar
Copy link
Member Author

Tyriar commented Jul 23, 2017

This one still needs a bunch of testing and fixing edge cases (removing/adding lines, splitting styles if cursor is not at the bottom, etc.)

@parisk
Copy link
Contributor

parisk commented Jul 24, 2017

Nah, I got too excited 😅.

@coveralls
Copy link

coveralls commented Jul 30, 2017

Coverage Status

Coverage decreased (-0.4%) to 70.081% when pulling b94d8a2 on Tyriar:484_truecolor_2 into bcff69b on sourcelair:master.

@parisk parisk mentioned this pull request Aug 3, 2017
13 tasks
@parisk parisk added this to the 3.0.0 milestone Aug 3, 2017
@coveralls
Copy link

coveralls commented Aug 5, 2017

Coverage Status

Coverage decreased (-0.5%) to 70.042% when pulling 999d00d on Tyriar:484_truecolor_2 into f5ba386 on sourcelair:master.

@mofux
Copy link
Contributor

mofux commented Aug 6, 2017

@Tyriar Short question about theming support for the base colors (0-15) when introducing true-color support:

I've read the comment here https://github.com/sourcelair/xterm.js/blob/v3/src/Terminal.ts#L61
and it reads like we are dropping the ability to theme the base colors (0-15). Is that correct?

@Tyriar
Copy link
Member Author

Tyriar commented Aug 7, 2017

@mofux support for 0-255 colors is remaining, a lot of the color code will be removed though. I think the only reason for the colors in JS is for matchColor which just matches 16 mil colors to the closest of the 255.

@Tyriar
Copy link
Member Author

Tyriar commented Sep 13, 2017

Closing, it's always available for reference.

@Tyriar Tyriar closed this Sep 13, 2017
@Tyriar Tyriar deleted the 484_truecolor_2 branch September 13, 2017 17:30
@Tyriar Tyriar restored the 484_truecolor_2 branch September 13, 2017 17:30
@Tyriar Tyriar added the reference A closed issue/pr that is expected to be useful later as a reference label Aug 31, 2018
@jerch jerch mentioned this pull request Jan 13, 2019
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
reference A closed issue/pr that is expected to be useful later as a reference work-in-progress Do not merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants