add '-h' flag for hexadecimal color in Data Structures. #1621
Conversation
…ymbol] This takes care of one part of pure-data#1620 still missing this implementation for [plot] and the other shapes. But this is a first implementation draft for testing and appreciation.
|
Cool! I have been proposing this a couple of times, but was too lazy to implement it :-)
I think it would be much nicer if we manage to do it without a flag. What about the following:
AFAICT, this would only fail if the user wants to set the color to |
|
how do we make sure that if the given field name (other than a hex-number) should expect a hex symbol to define the color? |
We know the type of the field. If it's a float field, we get a numeric color code; if it's a symbol field, we get a hex color string. |
|
Ok, I can try it, but would like to hear others as well, like @umlaeute , @danomatika , @jmmmp and stuff |
|
I guess that's the best solution. Another extra could be to also interpret negative numbers, which are read by all guis. |
This would be my suggestion... the arg type tells you the format. |
|
ok, no one oppose's @Spacechild1's suggestion then, I'll work on it!
can we have an extra issue for that? |
I actually don't think that is a good, though, as 'hexadecimal' is the current best practice in iemguis, as documented. |
When this was discussed on the list, I have actually proposed this, but @umlaeute rightfully pointed out that it's probably not a good idea to port this "hack" to data structures since we already have a better solution (= hex color codes). EDIT: @porres beat me to it :-) |
|
Well, I need help with this. The flag thing really made things a lot easier in the code as I also found an unused code structure and just made use of it. If I have to do things differently, it would require some surgery. the thing is that all field names expect a float value, as all the field names are variables for float arguments. Hence, we need a way to specify that this particular field will expect a symbol value, not a float. I know it looks uglier and it wasn't my first ideal alternative as well, but it just happens to be an elegant coding solution for now. |
|
my opinion is that data structures is already quite hard to use and understand and some objects already have several flags, so this wouldn't be that really bad... |
|
I'll have a look. If there is really no sane way to implement this, we can go for the flag, but we should at least try. |
draw shapes (polygons) and [plot]
great, please have a go at it, my take is done and works great, here's a test patch I'm really unconfortable touching this and changing things beyond this |
about the negative numbers and the hack, i have a question. Say that the user may want to use data structures to create art, and then use many colors, gradients and etc (now we would have more resolution with hex codes). But since they are symbols, they would populate the "symbol pool" (i don't know the correct name). If negative numbers would be allowed for the same purpose, would they be more efficient for this case? |
Me thinks that when someone is going for the fancy stuff like 2d gradients implemented with data structures, the extra memory consumed by the increased symbol table might not be the primary concern. Inversely, if you target a memory-restricted system, there are better options for creating fancy graphics than Pd's data structures. |
You're right that excessive use of hex colors can pollute the symbol table. Switching between a few colors wouldn't be an issue, but cycling through all 16777216 RGB colors would definitely bring Pd to its knees... In practice, it's more likely that you want to make a smooth gradient between two colors and you won't need more than a few dozens colors for that. But it's certainly a valid concern and there should probably be a warning in the docs. |
It's not only about memory, but also about performance! Pd's symbol table has a fixed size and there is no rehashing, so the more symbols you add, the slower it becomes. (Actually, this issue has been discussed on the list some time ago and as a result Miller increased the size from to 1024 to 16384.) Here's a simple test patch: Initially, adding 10 new symbols takes ca. 0.01 ms on my laptop. After adding 1,000,000 random symbols, it will already take 0.1-0.2 ms - which is 10-20x slower! Note that this is with the new symbol table size of 16384. If you try it with an older Pd version, it would take more like 1-2ms - which is 100-200x slower! My takeaway is that with the new symbol table size, it is very unlikely that you will run into actual performance issues, but still it's something to be aware of. |
|
just to add some more numbers: after generating all 16777216 symbols from this of course matches @Spacechild1's oberservation (but is explicit about creating all possible colors).
i concur. |
|
trying to resolve conflicts, but I might find it easier to reboot this :( |
This closes #1620