| 20 Jan 2021 |
 m4b | I was going to write a derive(Swift) proc macro but then I got distracted and I’m sure someone has already done something similarish | 07:22:46 |
 batmansmk | well for my immediate need, going away from nskit and swiftui is a bonus. Im doing a text editor - contenteditable is super buggy, most swift ui rich text experience are actually web backed... I dont care if it takes 2 months just to have a basic editor as long as we can cater and craft the exact experience we wish to have. | 07:24:05 |
| batmansmk | Thanks again for your ideas and experience. The devil is in the details! | 07:25:01 |
| m4b | Ah I see. Well I know iced (wgpu GUI library) works on iOS, and it also has clipboard support. Not sure if ithe clipboard works (never tried) on iOS but maybe check it out there ? Regardless you should always be able to call whatever clipboard function natively using objc rust library and link against correct framework, etc. but I think text editor is very doable, will be excited to checkout what you make, if you are able to share :) | 07:28:37 |
| m4b | Oh and since you’re using wgpu you’ll likely have very little cross platform issues. It’s quite magical. I used moltenvk before on macos and it was really, really unpleasant. It’s probably better now but I don’t care since I’m living in the future 😎 | 07:34:19 |
 2plus2isfive | Hi, I'm using wgpu and tracing. After my program panics, I receive hundreds of gfx_memory leaks and vulkan validation errors (memory leaks again) in the log, which is really annoying, because I have to scroll to find the panic message. I don't want to turn off logging for the crates in question completely, because I might get useful errors or warnings from them. Is it possible to work around this issue? | 07:40:40 |
 cwfitzgerald (wgpu, rend3) | In reply to @2plus2isfive:matrix.org
Hi, I'm using wgpu and tracing. After my program panics, I receive hundreds of gfx_memory leaks and vulkan validation errors (memory leaks again) in the log, which is really annoying, because I have to scroll to find the panic message. I don't want to turn off logging for the crates in question completely, because I might get useful errors or warnings from them. Is it possible to work around this issue? Latest gfx Master ignores validation during panic iirc | 07:42:15 |
| cwfitzgerald (wgpu, rend3) | Gpu-alloc (what replaced gfx-memory) will probably still yell at you tho | 07:43:06 |
| m4b | If we could have it somehow not log during panic(I brought this up before too) that would be amazing. It’s not like the log is useful since one can’t really do anything about it since program panicking. | 07:50:55 |
| cwfitzgerald (wgpu, rend3) | I think that's the case on master | 07:55:04 |
| m4b | Ok great! The validation errors were the huge spam. The gfx memory was still a little big but manageable. | 07:56:25 |
| m4b | Like I had to do cargo run 2> error.txt and then less that for my backtrace :P | 07:57:16 |
| cwfitzgerald (wgpu, rend3) | Master is also on gpu-alloc now, so the message is different | 07:59:16 |
 francesco.cattoglio | Can someone confirm the following:
there is no limit in wgpu for the size of a buffer, but if you try to allocate a humongous buffer, memory allocation on the GPU might fail because there is not enough contiguous memory on the GPU, while it would succeed if you requested the same amount of memory, but divided in a few smaller chunks. Especially on integrated GPU that have limited memory available. | 11:17:46 |
| francesco.cattoglio | Or do all modern gpu support virtual memory pages and other shenanigans so that I can just allocate and not care about that at all? | 11:25:51 |
 kvark | In reply to @m4b:matrix.org
Ok great! The validation errors were the huge spam. The gfx memory was still a little big but manageable. If you see an error log from gpu-alloc during panic, please file a quick issue to them and paste it. | 14:14:06 |
| kvark | francesco.cattoglio: we will have a limit on buffer sizes, it's just not exposed yet | 14:14:48 |
| kvark | Consider it to be 256mb to be safe | 14:15:00 |
| francesco.cattoglio | ty very much! | 14:16:14 |
 scoopr | If you are going to implement a custom text input component for uikit and not use any hacks (like hidden text fields), that will probably entail implementing UITextInput protocol, which while not impossible, is quite a lot of tedious details to get right (like, the ranges it talks about are probably utf16 indices). But that should give you the full IME etc. supports | 15:35:00 |
| scoopr | but it might not be fun to do within full rust. I would likely do it in objc myself, and then do the ffi with the c types. | 15:36:20 |
| scoopr | there are some efforts to use bindgen generate full bindings to uikit, not sure if the project had stalled though https://github.com/simlay/uikit-sys | 15:37:25 |
| scoopr | In reply to @batmansmk:matrix.org
well for my immediate need, going away from nskit and swiftui is a bonus. Im doing a text editor - contenteditable is super buggy, most swift ui rich text experience are actually web backed... I dont care if it takes 2 months just to have a basic editor as long as we can cater and craft the exact experience we wish to have. * If you are going to implement a custom text input component for uikit and not use any hacks (like hidden text fields), that will probably entail implementing UITextInput protocol, which while not impossible, is quite a lot of tedious details to get right (like, the ranges it talks about are probably utf16 indices). But that should give you the full IME etc. supports | 15:38:40 |
| francesco.cattoglio | One thing I find slightly confusing: to map a buffer I need to call a function on a BufferSlice, which implements Clone, while to unmap it I need to call a function on the original Buffer, which does not implement Clone, so it is a bit asymmetric. Is this something that may be changed in the future? | 16:27:59 |
| kvark | well, either way, both functions are &self, so you can have multiple clones of that reference | 16:30:16 |
| francesco.cattoglio | Right, that would require to take care of the lifetimes by hand, but that is doable. | 16:33:19 |
| kvark | I mean, you can literally do today:
let buffer = device.create_buffer();
let ref1 = &buffer;
let ref2 = ref1; // copy
ref2.unmap();
| 16:38:13 |
| kvark | * I mean, you can literally do today:
let buffer = device.create_buffer();
let ref1 = &buffer;
let ref2 = ref1; // copy
ref2.unmap();
| 16:38:40 |
| kvark | so the buffer slice thing doesn't make any difference with regards to Sync or Clone | 16:39:05 |
 g0wen | In reply to @kvark:matrix.org
g0wen: looks like we need to update the gecko branch! Please remove the x11 feature from the ones wgpu-core requests from gfx-backend-gl, locally, to test I removed the x11 feature from the features requested for gfx-backend-gl in the main Cargo.toml on the gecko branch, I can't see gfx-backend-gl in the wgpu-core Cargo.toml on the gecko branch, though it is present there on master (without the x11 feature requested). With the x11 feature request removed, the examples compile with no issues for me. :) | 17:42:29 |
